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(54) Geographic database 

(57) A geographic database for use with a naviga- 
tion application program that provides navigation fea- 
tures to an end-user. The geographic database includes 
data entities that represent segments of roads and ad- 
ditionally includes data entities that represent aggrega- 
tions of segments of roads. The data entities that repre- 
sent aggregations of segments of roads are used during 
a route calculation by the navigation application to sup- 
press evaluation of roads of lesser functional rank there- 
by enhancing performance of the navigation system. 
According to one aspect, each of the data entities that 
represent segments of roads that represents a segment 
of a road that together with at least one other segment 
of a road forms part of an aggregation which is repre- 
sented by one of the data entities that represent aggre- 
gations of segments of roads includes a reference there- 
to. According to another aspect, each of the data entities 
that represent aggregations of segments of roads refers 
to data entities that are abbreviated representations of 
the segments of roads included in the represented ag- 



gregation. Each of the data entities that are abbreviated 
representations of the segments of roads refers to a cor- 
responding one of the data entities that represent seg- 
ments of roads that represents the same respective seg- 
ment of road. According to this aspect, at least some of 
the data entities that represent aggregations of. seg- 
ments of roads are stored separately from the data en- 
tities that are abbreviated representations of the seg- 
ments of roads included in the represented aggregation. 
According to a further aspect, the navigation application 
program uses the references between the data entities 
that represent segments of roads, the data entities that 
represent aggregations of segments of roads, and the 
data entities that are abbreviated representations of the 
segments of roads included in the represented aggre- 
gation to provide navigation features, including evaluat- 
ing which data entities to use for route calculation and 
ascertaining whether a solution route has been found. 
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Descripti n 

REFERENCE TO RELATED APPLICATION 

[0001] The present application is related to the co- 
pending application entitled "INTERLEAVING OF DATA 
TYPES IN A GEOGRAPHIC DATABASE AND METH- 
ODS FOR USE THEREOF IN A NAVIGATION APPLI- 
CATION" filed on even date herewith, the entire disclo- 
sure of which Is incorporated by reference herein. 

BACKGROUND OF THE INVENTION 

[0002] The present invention relates to a system and 
nnethod for facilitating access to and use of geographic 
data used with a navigation application progrann that 
provides navigating features and functions to an end- 
user, and more particularly, the present invention relates 
to a geographic database that includes data which rep- 
resent segments of roads, and in addition includes data 
which represent aggregations of certain of these seg- 
ments of roads so that a navigation application program 
using the geographic database can use either or both 
of these kinds of data thereby facilitating certain func- 
tions and enhancing performance. 
[0003] Computer-based navigation application pro- 
grams are available that provide end-users (such as 
drivers of vehicles in which the navigation systems are 
installed) with various navigating functions and features. 
For example, some navigation application programs are 
able to determine an optimum route to travel by roads 
between locations. Using input from an end-user, and 
optionally from equipment that can determine one's 
physical location (such as a GPS system), a navigation 
application program can examine various routes be- 
tween two locations to determine an optimum route to 
travel from a starting location to a destination location 
in a geographic region. The navigation application pro- 
gram may then provide the end-user with information 
about the optimum route in the form of instructions that 
identify the maneuvers required to be taken by the end- 
user to travel from the starting location to the destination 
location. If the navigation system Is located in an auto- 
mobile, the instructions may take the form of audio in- 
structions that are provided along the way as the end- 
user is traveling the route. Some navigation application 
programs are able to show detailed maps on computer 
displays outlining routes to destinations, the types of 
maneuvers to be taken at various locations along the 
routes, locations of certain types of features, and so on. 
[0004] In order to provide these and other navigating 
functions, the navigation application program uses one 
or more detailed databases that include data which rep- 
resent physical features in a geographic region. The de- 
tailed database may include data representing the roads 
and intersections in a geographic region and also may 
include information about the roads and intersections in 
a geographic region, such as turn restrictions at inter- 



sections, speed limits along the roads, street names of 
the various roads, address ranges along the various 
roads, and so on. 

[0005] One difficulty in providing geographic data for 
5 use by a navigation application program relates to the 
efficient utilization of the available computer resources 
of the navigation system on which the navigation appli- 
cation program is run. Computer-based navigation ap- 
plication programs are provided on various platforms in- 
to eluding some with relatively limited computer hardware 
resources. For example, navigation systems may be lo- 
cated in vehicles or may be hand-held. These types of 
navigation systems typically have relatively limited com- 
puter resources, such as limited memory and relatively 
is slow I/O. I n order to provide a high a level of functionality 
in such systems, it is required that the available compu- 
ter resources be used efficiently. 
[0006] Given the relatively large size of the geograph- 
ic database necessary to provide a desired level of nav- 
20 igating functionality to the end-user, it is accepted that 
all the data records for an entire geographic region can- 
not be loaded into the memory of the navigation system 
at the same time This is especially true for navigation 
system platforms with limited resources, such as sys- 
25 tems installed in vehicles or hand-held systems. Due to 
the limited memory resources of these navigation sys- 
tems, it is necessary to toad geographic data as needed 
from a storage medium, such as a CD-ROM disk, into 
the memory of the navigation system for use by the nav- 
30 igation application program. Unfortunately, as men- 
tioned above, In these types of systems. I/O access from 
a storage medium may also be relatively stow. Thus, the 
relatively limited memory resources combined with the 
relatively slow I/O can limit the performance of some 
35 types of navigation systems, resulting in slow response. 
Aside from being undesirable, slow response in a navi- 
gation system may render the system useless for its in- 
tended purpose in certain circumstances. For example, 
if the navigation system is installed in a vehicle, the driv- 
40 er may require Information from the navigation system 
about a desired route in a matter of seconds in order to 
utilize the information while driving. If the navigation sys- 
tem requires more than several seconds to calculate a 
route, the driver may have moved beyond the point at 
45 Which the routing information provided by the navigation 
system is relevant. Therefore, it is important that navi- 
gation systems operate efficiently in order to provide 
navigating information relatively quickly. 
[0007] Navigation application programs may also be 
50 run on computer platforms that have In general greater 
memory resources and faster I/O, such as personal 
computers or networks. Although these systems may 
have more and faster resources, the considerations re- 
lated to the efficient use of geographic data still apply, 
55 but on a larger scale. With these types of systems, even 
greater functionality can be provided if the limitations im- 
posed by memory size and I/O are minimized. 
[0008] Techniques have been devised or implement- 
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ed to improve navigation system performance by organ- 
izing, structuring, or arranging the geographic database 
or the data in the database in particular ways. Because 
a navigation system uses geographic data in certain 
known and expected ways to perform known functions, 
the geographic data can be organized, structured, or ar- 
ranged in a manner that facilitates their use in these 
known ways by the navigation system. 
[0009] One technique that can be implemented in a 
geographic database to enhance operation of the navi- 
gation system is to minimize consideration of minor or 
secondary roads during calculation of a route. For ex- 
ample, when calculating a route between two locations, 
it might be inefficient to examine all the possible road 
segments that diverge from each intersection along a 
route being calculated, including all secondary streets 
and alleys. Instead, once a route being calculated is "on" 
amain road or expressway, it might be preferable to stay 
on main roads or expressways until it is necessary to 
exit to secondary roads as the destination is ap- 
proached. This suppression of minor or secondary 
roads can be implemented in various ways. 
[0010] One way to suppress consideration of minor or 
secondary roads is to use a ranking assigned to roads 
in a geographic region. The ranking can be related to a 
functional classification of the roads. Major roads upon 
which travel is generally faster are assigned a higher 
ranking and minor roads upon which travel is generally 
slower are assigned a lower ranking. Using these rank- 
ings, data records that represent higher ranked roads 
can be stored in a manner that eliminates or suppresses 
intersections with some or all of the lower ranked roads. 
One way to provide for this suppression is to store the 
higher ranked roads in one or more separate collections 
thereby forming separate layers in the geographic da- 
tabase. The higher layers are used when possible. 
Since the higher layers omit secondary roads, these 
slower roads are not considered when calculating the 
route, thereby minimizing the possible road segments 
to be investigated. This kind of database arrangement 
may facilitate the route calculation navigation function, 
thereby providing improved navigation system perform- 
ance. 

[0011] If a geographic database is organized in this 
manner, one difficulty to be addressed is how to make 
these different layers and/or rankings work together ef- 
ficiently. Eliminating the lower ranked roads from the 
higher layers of geographic data may speed up a route 
calculation function once a calculated route is on the 
higher ranked road. However by eliminating the data as- 
sociated with tower ranked roads from higher layers of 
data, it may be difficult to determine when the higher 
layers should be used or when the higher ranked roads 
can be successfully accessed from a lower ranked road. 
[0012] Accordingly, there continues to be a need for 
improvements that can provide better navigation system 
performance. Thus, it is an objective to provide improve- 
ments in the storage or use of geographic data that im- 



proves performance in a navigation system. Similarly, it 
is a further objective to develop navigation functions that 
can exploit the geographic database in improved ways. 

5 SUMMARY OF THE INVENTION 

[0013] To address the above concerns, according to 
one aspect of the present invention, there is provided a 
geographic database for use with a navigation applica- 

10 tion program that provides navigation featur^i^s to an 
end-user. The geographic database includes data enti- 
ties that represent segments of roads and additionally 
includes data entities that represent aggregations of 
segments of roads. The data entities that represent ag- 

15 gregations of segments of roads are used during route 
calculation by the navigation application program to 
suppress evaluation of roads of lesser functional rank 
thereby enhancing performance of the navigation sys- 
tem. According to one aspect, each of the data entities 

20 that represent segments of roads that represents a seg- 
ment of a road that together with at least one other seg- 
ment of a road forms part of an aggregation which is 
represented by one of the data entities that represent 
aggregations of segments of roads includes a reference 

25 thereto. 

[0014] According to another aspect, each of the data 
entities that represent aggregations of segments of 
roads refers to data entities that are abbreviated repre- 
sentations of the segments of roads included in the rep- 

30 resented aggregation. Each of the data entities that are 
abbreviated representations of the segments of roads 
refers to a corresponding one of the data entities that 
represent segments of roads that represents the same 
respective segment of road. According to this aspect, at 

35 least some of the data entities that represent aggrega- 
tions of segments of roads are stored separately from 
the data entities that are abbreviated representations of 
the segments of roads included in the represented ag- 
gregation. 

40 [0015] According to a further aspect, the navigation 
application program uses the references between the 
data entities that represent segments of roads, the data 
entities that represent aggregations of segments of 
roads, and the data entities that are abbreviated repre- 
ss sentations of the segments of roads included in the rep- 
resented aggregation, to provide navigation features, in- 
cluding evaluating which data entities to use for route 
calculation and ascertaining whether a solution route 
has been found. 

so 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0016] Figure 1 is a block diagram illustrating a navi- 
gation system. 

55 [0017] Figure 2 illustrates a map showing a geograph- 
ic region represented by the geographic database of 
Figure 1 . 

[0018] Figure 3 shows an expanded view of a portion 
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of the map of Figure 2. 

[0019] Figure 4 is an illustration of a single road seg- 
ment shown in the map of Figure 3. 
[0020] Figure 5 is a diagram illustrating the different 
types of data included in the geographic database of s 
Figure I for use with various navigation application func- 
tions. 

[0021] Figure 6 is a diagram illustrating separate lay- 
ers of data in the routing data shown in Figure 5. 
[0022] Figure 7 shows a map of the geographic region io 
of Figure 2 illustrating application of a parcelization 
method to spatially organized geographic data. 
[0023] Figure 8 is a diagram showing the arrange- 
ment of parcels of data in the geographic database of 
Figure 1 according to the parcelization method illustrat- is 
ed in Figure 7. 

[0024] Figure 9 is a diagram showing the arrange- 
ment of segment and node data records within a single 
parcel of the database of Figure 8. 
[0025] Figures 10A though 10D graphically illustrate 
the geographic features represented by aggregated 
segment data records. 

[0026] Figure 11 is a diagram illustrating inclusion of 
aggregated segment records in a parcel of routing data 
in layer above layer 0. 

[0027] Figure 12 is a diagram illustrating the compo- 
nents of an aggregated segment record and its associ- 
ated abbreviated record array of Figure 1 1 . 
[0028] Figure 13 is a diagram illustrating the compo- 
nents of the abbreviated segment record of Figure 12. 30 
[0029] Figure 14 is a diagram illustrating the compo- 
nents of the abbreviated node record of Figure 12. 
[0030] Figure 15 is a diagram illustrating the kinds of 
information included In a segment record included in lay- 
er 0-3 of the routing data. 

[0031] Figure 16 is a diagram illustrating inclusion of 
aggregated segment records in a parcels of a layer of 
routing data according to an alternative embodiment. 
[0032] Figure 17 is a diagram illustrating the compo- 
nents of an aggregated segment record and its associ- 
ated abbreviated record array of Figure 16. 
[0033] Figure 18 is a diagram representing one ar- 
rangement for Interleaving different types of data within 
a layer of data, 

[0034] Figure 19 is a diagram representing another ^5 
arrangement for interleaving different types of data with- 
in a layer of data. 

[0035] Figure 20 is a diagram representing still anoth- 
er arrangement for interleaving different types of data 
within a layer of data. 

[0036] Figure 21 is a diagram illustrating the steps in 
forming a geographic database having a portion with dif- 
ferent data types interleaved with each other, as shown 
in Figure 20. 

[0037] Figure 22 is a diagram of a map illustrating the 55 
application of a parcelization step in Figure 21 to geo- 
graphic data that represent features in the Illustrated re- 
gion. 



[0038] Figure 23 is a diagram of a kd-tree that corre- 
sponds to the parcelization step Illustrated in Figure 22. 

DETAILED DESCRIPTION OF THE PRESENTLY 
PREFERRED EMBODIMENTS 

L NAVIGATION SYSTEM - OVERVIEW 

[0039] Referring to Figure 1 , there is a block diagram 
of a navigation system 10. The navigation system 10 Is 
installed in a vehicle 1 1 , such as a car or truck, although 
in alternative embodiments, the navigation system 10 
may be located outside of a vehicle or may be imple- 
mented in various other platforms or environments, as 
described below. 

[0040] Referring to the embodiment illustrated in Fig- 
ure 1 , the navigation system 1 0 is a combination of hard- 
ware and software components. In one embodiment, 
the navigation system 10 includes a processor 12, a 
drive 14 connected to the processor 12, and a non-vol- 
atile memory storage device 16 for storing a navigation 
application software program 18, possibly as well as 
other information. The processor 12 may be of any type 
used in navigation systems, such as 32-bit processors 
using a flat address space, such as a Hitachi SH1, an 
Intel 80386, an Intel 960, a Motorola 68020 (or other 
processors having similar or greater addressing space). 
Processor types other than these, as well as processors 
that may be developed in the future, may also be suita- 
ble. 

[0041] The navigation system 10 may also include a 
positioning system 24. The positioning system 24 may 
utilize GPS-type technology, a dead reckoning-type sys- 
tem, or combinations of these, or other systems, all of 
which are known in the art. The positioning system 24 
may Include suitable sensing devices 25 that measure 
the traveling distance speed, direction, and so on, of the 
vehicle. The positioning system 24 may also include ap- 
propriate technology to obtain a GPS signal, in a manner 
which is known in the art. The positioning system 24 out- 
puts a signal 26 to the processor 1 2. The signal 26 may 
be used by the navigation application software 1 8 that 
is run on the processor 12 to determine the location, di- 
rection, speed, etc., of the navigation system 10. 
[0042] The navigation system 1 0 also includes a user 
interface 31 . The user interface 31 includes appropriate 
equipment that allows the end-user to input information 
into the navigation system. This input information may 
include a request to use the navigation features of the 
navigation system. For example, the input information 
may include a request for a route to a desired destina- 
tion. The Input information may also include other kinds 
of information. The equipment used to input information 
into the navigation system may include a keypad, a key- 
board, a microphone, etc., as well as appropriate soft- 
ware, such as a voice recognition program. The user 
interface 31 also includes suitable equipment that pro- 
vides information back to the end-user. This equipment 
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may include a display 27, speakers 29, or other means. 
[0043] The navigation system 10 uses a map data- 
base 40 stored on a storage medium 32. The storage 
medium 32 is installed in the drive 14 so that the map 
database 40 can be read and used by the navigation 
system. The storage medium 32 may be removable and 
replaceable so that a storage medium with an appropri- 
ate map database for the geographic region in which the 
vehicle is traveling can be used. In addition, the storage 
medium 32 may be replaceable so that the map data- 
base 40 on it can be updated easily. In one embodiment, 
the geographic data may be published by Navigation 
Technologies of Sunnyvale, California. 
[0044] In one embodiment, the storage medium 32 is 
a CD-ROM disk. In an alternative embodiment, the stor- 
age medium 32 may be a PCMCIA card in which case 
the drive 14 would be substituted with a PCMCIA slot. 
Various other storage media may be used, including 
fixed or hard disks, DVD (digital video disks) or other 
currently available storage media, as well as storage 
media that may be developed in the future. The storage 
medium 32 and the geographic database 40 do not have 
to be physically provided at the location of the navigation 
system. In alternative embodiments, the storage medi- 
um 32, upon which some or alt of the geographic data 
40 are stored, may be located remotely from the rest of 
the navigation system and portions of the geographic 
data provided via a communications link, as needed. 
[0045] The navigation application software program 
18 is loaded from the nonvolatile memory 16 into a RAM 
20 associated with the processor 12 in order to operate 
the navigation system. The navigation system 10 uses 
the map database 40 stored on the storage medium 32, 
possibly in conjunction with the output 26 from the po- 
sitioning system 24, to provide various navigation fea- 
tures and functions. The navigation application software 
program 18 may include separate applications (or sub- 
programs) that provide these various navigation fea- 
tures and functions. These functions and features may 
include route calculation, map display, vehicle position- 
ing (e.g.. map matching), route guidance (wherein de- 
tailed directions are provided for reaching a desired des- 
tination), destination resolution capabilities, and other 
functions. 

n. THE GEOGRAPHIC MAP DATABASE 
a. Overview. 

[0046] In one present embodiment, the speed and/or 
functionality of a navigation system can be enhanced by 
a combination that includes improvements in the stor- 
age, arrangement, and/or structuring of the geographic 
data used by the system to facilitate the use of the data 
by some of the functions in the navigation application 
program in the systems that use the data. Based upon 
the manner in which the geographic data are stored, ar- 
ranged, and/or structured, functions in the navigation 



application program that access and use the data can 
implement routines that exploit the improvements incor- 
porated into the geographic data. This combination can 
result in overall improved performance by the navigation 
5 system. 

[0047] The map database 40 contains information 
about the roadway network in the geographic region. In 
one embodiment, the map database 40 includes node 
data and segment data. Node data represent physical 
10 locations in the geographic region (such as roadway in- 
tersections and other positions) and segment data rep- 
resent portions of roadways between the physical loca- 
tions represented by nodes. Each road segment in the 
geographic region is represented by a road segment da- 
is ta entity (i.e., a record) in the map database 40. Each 
road segment data record in the map database has two 
nodes which represent the coordinate positions at each 
end of the road segment represented by the road seg- 
ment data record. The information included in the node 
20 and segment data entities is explained with reference to 
Figures 2 and 3. (The terms "nodes" and "segments" 
represent only one terminology for describing these 
physical geographic features and other terminology for 
these features is intended to be encompassed within the 
25 scope of these concepts.) 

[0048] Figure 2 illustrates a map 110 showing a geo- 
graphic region 112. A plurality of locations 114 are 
shown to be located in the geographic region 112. Each 
of the locations 114 represents a place or point in the 
30 geographic area 1 1 2 at which there is located a feature 
about which it is desired to include information in a ge- 
ographic database. Each of these locations 114 has a 
unique physical location (latitude, longitude, and option- 
ally absolute or relative altitude) and each of the loca- 
ls tions 114 can be uniquely identified by its two dimen- 
sional (or three dimensional) geographic coordinates, (t. 
e., latitude, longitude, and optionally altitude). A location 
114 may correspond to an intersection at which two or 
more roads meet, a point along a road segment at which 
40 the direction of the road changes, a point along a road 
segment at which the speed limit changes, a point at 
which a road reaches a dead end, and so on. The loca- 
tion 114 may correspond to a position of a point-of-in- 
terest, such as a hotel or civic center, a boundary of a 
45 natural feature, such as a lake, or a position along a rail- 
road track or terry. The locations 114 may correspond 
to anything physically located in the geographic area 
112. 

[0049] Figure 3 shows an expanded view of a portion 
so 116 of the map 110. The portion 116 in Figure 3 illus- 
trates part of the road network 120 in the geographic 
region 112. The road network 120 includes, among oth- 
er things, roads and intersections located in the geo- 
graphic region 1 1 2. As shown in Figure 3 in the illustrat- 
55 ed portion 116 of the map 110, each road in the geo- 
graphic region 112 is composed of one or more seg- 
ments, 122(1). 122(2)... 122(n). In one embodiment, a 
road segment represents a portion of the road. In Figure 



6 



BNSDOCID: -sEP 0943895A2_L> 



9 



EP 0 943 895 A2 



10 



3, each road segment 1 22 is shown to have associated 
with it two nodes 123: one node represents the point at 
one end of the road segment and the other node repre- 
sents the point at the other end of the road segment. A 
single road segment 1 22 and its two associated nodes 
123(a) and 123(b) are illustrated in Figure 4. The node 
at either end of a road segment may correspond to a 
location at which the road meets another road, e.g., an 
intersection, or where the road dead ends. (An intersec- 
tion may not necessarily be a place at which a turn from 
one road to another is permitted, but represents a loca- 
tion at which one road and another road have the same 
latitude and longitude.) 

[0050] In addition, if the road segment 122 is other 
than straight (e.g., it bends, turns, etc.), the road seg- 
ment 122 may include one or more shape points 124 
between its end points 123. Shape points 124 provide 
geographic positions (i.e., latitudes, longitudes, and op- 
tionally, altitudes) along the length of the road segment 
to accurately represent the true physical locations of the 
road segment along its length. Shape points 124 are 
used to assist in vehicle positioning, map display, etc. 
[0051] In one type of geographic database, there is at 
least one database entry (also referred to as "entity" or 
"record") for each road segment represented in a geo- 
graphic region. This road segment data record may 
have associated with it information (such as "attributes", 
"fields", etc.) that allows identification of the nodes as- 
sociated with the road segment and or the geographic 
positions (e.g. the latitude and longitude coordinates) of 
the two nodes. In addition, the road segment record may 
have associated with it information (e.g.. more "at- 
tributes", "fields", etc.), that specify the speed of travel 
on the portion of the roadway represented by the road 
segment record, the direction of travel permitted on the 
road portion represented by the road segment record, 
what If any turn restrictions exist at each of the nodes 
which correspond to intersections at the ends of the road 
portion represented by the road segment record, the 
street address ranges of the roadway portion represent- 
ed by the road segment record, the name of the road, 
and so on. Each segment data entity that represents an 
other-than-straight road segment may include one or 
more shape point data attributes that define the other- 
than-straight shape of the road segment. The various 
attributes associated with a road segment may be in- 
cluded in a single road segment record, or preferably 
are included in more than one type of road segment 
record which are cross-referenced to each other. 
[0052] In a geographic database that represents the 
region 112, there may also be a database entry (entity 
or record) for each node in the geographic region. The 
node data record may have associated with it informa- 
tion (such as "attributes", "fields", etc.) that allows iden- 
tification of the road segment(s) that connect to it and/ 
or its geographic position (e.g., its latitude and longitude 
coordinates). 



b. Separate subsets of Qeopraphic data 

[0053] One way that the accessing of geographic data 
can be enhanced for performing various navigation 

s functions is to provide separate collections or subsets 
of the geographic data for use by each of the separate 
functions in the navigation application program. Each of 
these separate subsets is tailored specifically for use by 
one of the functions. For instance, the route calculation 

10 function normally uses only a portion of all the informa- 
tion in the geographic database that Is associated with 
a segment of a road. When the route calculation function 
is being run, it may require information such as the 
speed along a road segment, turn restrictions from one 

15 road segment to another, and so on. However, the route 
calculation function does not necessarily require the 
name of the road to calculate a route. Similarly, when 
using the map display function, some of the Information 
associated with a road segment, such as the speed lim- 

20 its or turn restrictions, is not required. Instead, when the 
map display function is run, it uses only a portion of the 
information associated with the road segment, such as 
the shapes and locations of roads, and possibly the 
names of the roads. Even further, when the route guid- 

25 ance function is being run, some of the information as- 
sociated with a segment of a road, such as the speed 
and turn restrictions, is not required. Instead, when the 
route guidance function is being run, it uses information 
that includes the name of the road represented by the 

30 road segment, the address range along the road seg- 
ment, any signs along the road segment, and so on. Al- 
though there may be some overlap as to the types of 
information used by the various navigation functions, 
some of the data used by any one of these navigation 

35 functions is not used by another of the functions. If all 
the information relating to each road segment were as- 
sociated with It as a single data entry in a single data- 
base, each data entity record would be relatively large. 
Thus, whenever any one of the navigation functions ac- 

40 cessed an entity record. It would have to read into mem- 
ory a significant amount of information much of which 
would not be needed by the navigation function. More- 
over, when reading the data entity from disk, relatively 
few data entitles could be read at a time since each data 

45 entity would be relatively large. 

[0054] In order to provide the information In the geo- 
graphic database in a format more efficient for use by 
each of the navigation functions, separate subsets of the 
entire geographic database for a given geographic re- 

50 gion are provided for each of the different types of nav- 
igation functions to be provided in the navigation appli- 
cation program. Figure 5 illustrates the geographic da- 
tabase 40 comprised of separate routing data 1 36, car- 
tographic data 137 (for map display), maneuver data 

55 1 38 (for route guidance), and point-of-interest data 1 39. 
A geographic database may be defined with fewer or 
more subsets than these, and other types of data may 
be defined and included. 
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[0055] Each subset of data includes only the data re- 
quired to be used by a particular navigation function. 
There Is sonne overlap of data between each of these 
subsetS: with the result that sonne parts of the informa- 
tion may be included in more than one subset. For ex- 
ample, both the road segment data entity in the routing 
data subset as well as the road segment data entity in 
the cartographic data subset may include attributes 
identifying the nodes located at the ends of the seg- 
ments. Although this duplication may result in a larger 
overall data storage requirement, each of the navigation 
functions benefits from the resultant efficiency of han- 
dling smaller amounts of data. 

[0056] Providing for separate subsets of geographic 
data for each of the navigation functions also takes into 
account that usage of each of these navigation functions 
relates to the others of the navigating functions in ex- 
pected ways. For example, an end-user may first want 
to view a present position, then enter a destination, then 
receive instructions how to start toward the destination, 
then observe a map showing the initial portion of the 
route, then receive further instructions, then have a map 
displayed of the next portion of the route, and so on. 
Because of this type of expected usage, dividing the da- 
ta into subsets provides for efficient use of the data when 
using each separate function. 

[0057] Although the division of the geographic data in- 
to subsets provides for efficient use of the data by each 
of the different navigation functions, it becomes neces- 
sary to provide that the different navigating functions 
that use these different subsets of the database work 
together. For example, in the example mentioned 
above, after a user obtains a calculated route, it may be 
desired to display a map on a computer display with the 
calculated route highlighted. In order to accomplish this, 
the routing subset 136 of geographic data is accessed 
first to obtain the routing road segment data entities for 
the optimum route, and then the cartographic subset 
137 of the geographic database is accessed to obtain 
the cartographic road segment data entities corre- 
sponding to the routing data entities. To permit these 
data subsets to work together, index files 140 may be 
included that provide cross references, search trees, or 
other data finding techniques. 

c. Layering of oeopraphic data 

[0058] Another way that the geographic data can be 
organized to enhance their use is to provide the data in 
layers. Some of the navigation functions, such as the 
map display function and the route calculation functions, 
may use data at different levels of detail. For example, 
when using the map display function, it Is sometimes 
desired to provide for panning and zooming. Zooming 
can be done more efficiently if the data are organized 
Into layers, with greater detail at the lower layers and 
less detail at the higher layers. When using the route 
calculation function, it is also advantageous to use the 



data at different levels of detail. For example, when cal- 
culating a route between two locations, it would be inef- 
ficient to examine all the possible road segments that 
diverge from each intersection along the route, Including 
5 secondary streets and alleys. Instead, once a route is 
"on" a main road or expressway, it is generally prefera- 
ble to stay on main roads or expressways until it Is nec- 
essary to exit to secondary roads as the destination is 
approached. If the routing data are layered, higher lay- 
to ers that omit secondary roads can be used when pos- 
sible to minimize the possible road segments to be In- 
vestigated when calculating the route. Therefore, within 
some of the subsets of data types, the geographic data 
are provided in separate collections or groups corre- 
15 spending to separate layers. 

[0059] To implement layering, each road segment da- 
ta record in the map database 40 also identifies the rank 
of the corresponding portion of the roadway that it rep- 
resents. A rank of a road segment may correspond to 
20 its functional class. Road segments having a rank of "4*' 
may include high volume, controlled access roads, such 
as expressways and freeways. Road segments having 
a rank of "3" may be high volume roads with few speed 
changes, but are not necessarily controlled access 
25 roads. The lower ranked roads handle corresponding 
lower volumes and generally have more speed changes 
or slower speeds. Road segments having a rank of "0** 
can handle the lowest volumes. For example, these may 
include side streets, alleyways, etc. 
30 [0060] The rank of a road segment data entity also 
specifies the highest data layer in which a road segment 
entity is Included. For example, referring to Figure 6, the 
routing type data 1 36 may include five separate layers 
of the data, RO, R1 , R2, R3, and R4. each comprising 
35 a separate collection of the routing data with a different 
level of detail, which can be used by the route calculation 
function. In the routing data type of the geographic da- 
tabase, layer 0 ("RO)" includes the road segment data 
entities (and some or all of their corresponding routing 
40 data attributes) having a rankof "Cor higher Thus, lay- 
er 0 includes road segment data entities corresponding 
to all the portions of all the roads in the geographic re- 
gion. Layer 1 of the routing data 137 comprises a sep- 
arate subset (or collection) of the routing data and in- 
45 dudes only the routing segment data entitles (and some 
or all of their corresponding routing data attributes) hav- 
ing a rank of "1 " or higher. Layer 2 of the routing data 
comprises a separate subset of the routing data and in- 
cludes only the routing segment data entities (and some 
so or all of their corresponding navigation data attributes) 
having a rank of level 2 or higher, and so on. A highest 
layer (layer n) includes only records having a rank of n. 
In a present embodiment, n is equal to 4, although in 
other embodiments, n may be any number greater than 
55 0. Each higher layer includes fewer records, however 
these records represent roads upon which travel is gen- 
erally faster 

[0061] Similarly, the other types of data, such as the 
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cartographic subset type 1 37 may include separate col- 
lections of the data, each with a different level of detail, 
which can be used by the map display function. Using 
these different layers of cartographic data, the map dis- 
play function can provide rapid panning and zooming. 
[0062] Although the organization of some of the data 
into layers results in some duplication of the data, the 
increased efficiency provided by layering generally off- 
sets any disadvantages. As with the use of separate 
types of data mentioned above, the need arises to allow 
these layers to work together. The index files 1 40, which 
include cross references, search trees, or other finding 
techniques, may be provided for this purpose. 

d. Spatial access to peoQraphic data 

[0063] Organizing the data into subsets or types and 
layering the data of some of the types provide separate 
collections of the data in sizes that are more managea- 
ble by each of the navigation functions. With respect to 
some subset types and layers of these types, the data 
can be further organized to facilitate spatial access. 
[0064] Several of the navigation functions provided in 
a navigation system may require access to the geo- 
graphic data spatially. One way this arises is that a func- 
tion in a navigation application program requires finding 
a data entity record in a geographic database given the 
physical location represented by the data entity in the 
geographic region. The data entity may be a road seg- 
ment record that represents a portion of a road in the 
geographic region and the function may require finding 
the road segment record based upon the physical loca- 
tion in the geographic region of the portion of the road 
represented by the road segment record. Another way 
spatial access arises is when a function in a navigation 
application program requires finding several or all of a 
type of data records located close to a location in the 
geographic region or within a defined area in the geo- 
graphic region. For example, a function may require all 
road segment records that represent road segments en- 
compassed within a rectangle defined by geographical 
coordinates (x, x+n) latitude and (y, y+m) longitude. 
[0065] Assuming that all the data records for a given 
ntire geographic region cannot be loaded into memory 
at the same time due to limited memory resources of the 
navigation system in which the navigation application 
program Is being run, it would be desirable to load into 
memory only those data that are needed. Since some 
of the navigation functions require accessing data spa- 
tially, it would be advantageous to provide a means to 
load data into memory based generally upon the phys- 
ical geographic locations of the features which the data 
represent or upon the geographical proximity of the fea- 
tures which the data represent. This can be provided by 
organizing the data so that they are located in the data- 
base and/or on the medium based upon the geographic 
locations of the features which are represented by the 
data. Various techniques can be used to provide for spa- 



tial access. One kind of technique, parcelization. is de- 
scribed below. 

e. Parcelization. 

s 

[0066] Parcelization is included among the tech- 
niques that can be used to facilitate the use of geograph- 
ic data by navigation systems. Assuming that all the data 
records for a given entire geographic region cannot be 

10 loaded into the memory of the navigation system at the 
same time, due to limited memory resources of the nav- 
igation system in which the navigation application pro- 
gram is being run, it would be desirable to load into 
memory only those data that are needed to perform a 

15 desired function. In order to accomplish this, data In the 
geographic database 40 are organized in a manner that 
minimizes the number of times that the medium must be 
accessed and read in order to perform a navigation func- 
tion. To provide for this, the data are organized into par- 

20 eels. When data are parcelized, the plurality of data 
records that together comprise the geographic data are 
grouped together into separate groups or parcels. A par- 
cel of data is established to contain data that are always 
accessed together. This may relate to the quantity of da- 

25 ta that can be accessed in a single disk access, although 
it may be related to some other factor. For some types 
of media such as a CD-ROM disk, a parcel may be es- 
tablished to be a 1 6 Ki lobyte quantity of data. (Other siz- 
es of data may be used including 1 K, 2 K, 4 K, 8 K, 32 

30 K, and so on. The portions of the geographic database 
are generally formed in sizes of 2" Kilobytes, wherein n 
is an integer value greater than 1 .) 
[0067] Parcelization can be used in conjunction with 
spatial access to facilitate the use of data to enhance 

35 performance of the navigation system. When geograph- 
ic data are organized spatially, features that are close 
together physically in the geographic region are repre- 
sented by data records that are physically (or logically) 
close together in the database. Geographic data can be 

40 both parcelized and spatially organized to take advan- 
tage of both these techniques. 

[0068] For purposes of forming the data into parcels, 
the data may be first separately organized into different 
types, such as routing 136. cartographic 137, maneuver 

45 138, points of interest 139, and so on. Some of these 
kinds of data may be parcelized spatially in order to fa- 
cilitate use of the data by the navigation functions and 
others of these kinds of data may not be parcelized spa- 
tially. Spatially-parcelized data are arranged so that the 

50 data that represent geographically proximate features 
are located logically and/or physically proximate in the 
database 40 and/or on the medium 32. For some of the 
navigation application functions, spatial parcelization of 
their respective data provides for reading closely related 

55 geographic data from the medium more quickly and 
loading related geographic data into memory where 
they can be used. This kind of organization minimizes 
accessing of the storage medium 32 and may speed up 



9 



BNSDOCID: <EP 0943895A2_I_> 



15 



EP 0 943 895 A2 



16 



operation of these navigation functions. The routing da- 
ta 1 36 (in Figure 5) are included among the kinds of data 
that may be spatially organized. 
[0069] There are a number of different procedures 
that can be used for parcelizing spatially organized ge- 
ographic data. For example, a simple parcetization 
method may provide for separating the geographic data 
into a plurality of parcels or groupings wherein the data 
in each parcel represent features encompassed within 
a separate one of a plurality of regular sized rectangles 
which together form a regular, rectangular grid over the 
geographic region. Another method for parcelization is 
to separate the data into parcels encompassed within 
rectangular areas where each of the rectangles is 
formed by a bisection of rectangles encompassing parts 
of the region until a parcel size below a maximum 
threshold is obtained. In addition, parcelization proce- 
dures are disclosed in the copending application Ser. 
No. 08/740,295. filed October 25, 1996, the entire dis- 
closure of which is incorporated by reference herein, 
and parcelization procedures are also described in the 
copending patent application Ser. No. 08/935,809, filed 
September 5. 1997, the entire disclosure of which is in- 
corporated by reference herein. Still another method of 
parcelization to which the disclosed subject matter can 
be applied is described in U.S. Pat No. 4.888,698. 
[0070] Parcelization of spatially organized data is il- 
lustrated with reference to Figures 7-9. Figure 7 shows 
the map 110 of the geographic region 112. previously 
illustrated in Figure 2. The plurality of positions 114 (rep- 
resented by the dots or points) are shown to be located 
on the map 1 1 0. In Figure 7. a grid 21 7 overlays the ge- 
ographic region 112 represented by the map 110. The 
grid 217 divides the geographic region 112 into a plural- 
ity of rectangular areas 219. The grid lines of the gnd 
217 represent the boundaries of rectangular areas 21 9. 
These rectangular areas 219 may be all the same size 
or may have different sizes depending upon the proce- 
dure used for parcelization. Likewise, the locations of 
the boundaries may depend on the parcelization proce- 
dure used. In general, when usingany of the procedures 
for spatial parcelization, the data records of a particular 
type of data which represent features that are encom- 
passed within each rectangular area 219 are grouped 
together in a separate parcel of data. Referring to Fig- 
ures 8 and 9, the plurality of data records, such as the 
road segment records 322 and the node records 323 
that comprise the geographic database 40, are collected 
into separate groupings called parcels 220. With respect 
to the spatially organized data, each parcel 220 in Fig- 
ures 8 and 9 includes one or more data records 322, 
323, which represent the geographic features encom- 
passed within a separate one of the plurality of rectan- 
gles 219 shown in Figure 7. 

[0071] As shown in Figures 8 and 9, the parcels 220 
are stored to form the database 40 so that the data in 
each parcel 220 are logically and/or physically grouped 
together. A parcel 220 may represent the physical quan- 



tity of data that can be accessed at a time by the navi- 
gation system. When a parcel of data is accessed, all of 
its data records 322. 323, are read from the medium into 
the memory of the navigation system at the same time. 

5 With reference to the map 110 of Figure 7. this means 
that all the data records, such as the segment records 
322 or node records 323, of a spatially organized type 
of data encompassed within each rectangle 21 9 are ac- 
cessed together as a group. It can be appreciated that 

10 for certain kinds of navigation functions, it is desirable 
to have in memory at the same time all the data records 
that represent features that are physically close together 
in the geographic region. 

[0072] As the parcels 220 are formed for these types 

15 of data, the parcels are ordered. Various types of order- 
ing may be used. In general, it is preferred that the par- 
cels be ordered in a manner that minimizes searches 
for data. One way to order spatially organized parcels 
is to use a depth-first ordering from a kd-tree index within 

20 each type of data. This provides an ordering similar to 
Peano-key ordering. Parcels may be stored on disk (i. 
e.. medium 32 in Figure 1) in this approximate Peano- 
key order. One or more indices, such a kd-tree. can be 
used to access parcels spatially. This index is useful for 

25 initial location of an arbitrary position, such as when a 
program in a navigation system initially locates the map 
data corresponding to a current vehicle position. As the 
parcels 220 are ordered, each may also be assigned a 
unique parcel identifier (e.g.. a "paf'cel ID"). The parcel 

30 ID may be used to identify the parcel and/or its location 
on the medium. 

[0073] (As mentioned above, some kinds of data are 
not spatially organized. Each parcel of non-spatially or- 
ganized data does not necessarily correspond to any of 
35 the rectangular areas 219 in Figure7. For example, data 
that represents the names of streets may be organized 
alphabetically instead of spatially.) 



40 



SEGMENT AGGREGATION 



a. Overview. 



[0074] In a present embodiment, the geographic da- 
tabase includes data records that represent aggrega- 

45 tions of road segments. These data records that repre- 
sent aggregations of segments of roads are included in 
the database in addition to the data records (e.g.. 322 
in Figure 9) that represent the separate road segments 
from which the aggregations are formed. Using data 

50 records that represent aggregations of roads has the po- 
tential to provide several advantages. Using records 
that represent aggregations of segments of roads may 
reduce the number of road segments that need to be 
explored during route calculation. It is also possible that 

ss if records that represent road s gment aggregations are 
used, the number of segments that make up a final cal- 
culated route may be reduced thereby improving navi- 
gation system performance. In addition, it is also possi- 
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ble that if records that represent road segment aggre- 
gations are used, the overall size of the database may 
be reduced. 

[0075] One way to form data records that represent 
aggregations of segments of roads derives from the for- 
mation of multiple layers of data in the database. As 
mentioned above, a road segment data entity includes 
a rank attribute that corresponds to a functional classi- 
fication of the represented road segment. In a present 
embodiment, the rank attribute is used to form layers of 
the geographic database. The rank attribute specifies 
the highest data layer in which the road segment is rep- 
resented. The lowest layer, i.e., "RO", of the route cal- 
culation data 136 includes all routing road segment 
records (i.e.. road segment records of all ranks). In each 
succeeding higher layer, the lowest-ranked road seg- 
ment records are omitted. As a result, these higher lay- 
ers include a number of "bivalent" nodes, i.e. nodes be- 
tween at which exactly two segments meet or intersect. 
(It is also possible to form bivalent nodes under other 
circumstances in the geographic database, for example 
when a road segment crosses an administrative bound- 
ary.) If attributes that are relevant to route calculation 
are the same for the two road segment records that are 
joined by a bivalent node, an aggregated segment 
record can be formed that suppresses or drops the bi- 
valent node. 

b. Physical representation of apprepated sepments. 

[0076] Figure IDA is an illustration of a plurality of 
road segments 122 which are represented by road seg- 
ment records in layer 0 of the routing data 136. A node 
1 23 is associated with each of the end points of each of 
the road segments 1 22. In layer 0, all the road segments 
of all the ranks are represented by data entities. Figure 
10B shows the same plurality of segments 122 and 
nodes 123 shown in Figure 10B, except that the road 
segments having a rank of "0" are illustrated in dashed 
lines. Figure 10C shows these lower ranked road seg- 
ments removed. (Figures 10B and IOC illustrate inter- 
mediate stages and are not representative of a layer.) 
Figure 10C illustrates the segments 122 and nodes 123 
in layer 1. As illustrated in Figure IOC, elimination of 
road segments having a rank of 0 results in some re- 
maining nodes joining only two road segments. It may 
be possible to speed up route calculation if little or no 
calculation is performed when calculating a route that 
traverses these kinds of nodes. To take advantage of 
this arrangement, the segments 122 (labeled SI, S4, 
S5, S6, S7, S9, and S11) are represented by an aggre- 
gated segment record which is formed and stored in the 
geographic database 40. This aggregated segment 
record represents the aggregation, labeled AG 12, of the 
separate road segments, as shown in Figure 10D. 



c. Apprepation criteria. 

[0077] Figures 10A-10D illustrate the conditions un- 
der which it is possible to form an aggregated segment 

5 record. According to one alternative embodiment, ag- 
gregated segment records are always formed whenever 
two and only two road segments are joined by a single 
node. However, under some circumstances, it may be 
preferable to refrain from forming an aggregated seg- 

10 ment record under these conditions. For example, if cer- 
tain attributes of adjacent road segments differ, it may 
be preferable not to form an aggregated segment record 
to represent them in aggregation even if they are the 
only road segments joined by single node. Thus, ac- 

15 cording to an alternative embodiment, attributes of ad- 
jacent road segment records are examined to determine 
whether the represented road segments are simitar 
enough to be represented by an aggregated segment 
data record. Various criteria may be used tor making this 

20 determination. For example, in one alternative embodi- 
ment, it may be required that all attributes in adjacent 
road segments be the same in order to form an aggre- 
gated segment record. In another alternative embodi- 
ment, it may be required that only certain attributes be 

25 the same in adjacent road segments to form an aggre- 
gated segment record. In this latter alternative, some at- 
tributes may be permitted to differ between adjacent 
road segments. 

[0078] In one present embodiment, an aggregated 
30 segment record is formed where each consecutive pair 
of adjoining road segments has the same name, rank, 
speed category, lane category, and access characteris- 
tics, among other characteristics. However, formation of 
an aggregated road segment is not permitted if the ad- 
35 jacent road segments include a restricted driving 
maneuver, a vehicle restriction; a direction of travel re- 
striction, a gate, a high-occupancy-vehicle restriction, a 
bifurcated roadway, a toll booth, or signage, among oth- 
er restrictions. 

40 [0079] The above critena only represent examples of 
the kinds of attributes that may be evaluated to deter- 
mine whether an aggregated segment record is formed 
from two or more adjacent segments. Other criteria may 
be suitable. 

45 

d. Process for forming apprepated sepments. 

[0080] When forming aggregated segment records 
using any embodiment that requires an evaluation of 

50 whether the adjacent road segments meet some crite- 
ria, the first step is to identify possible end nodes for 
aggregated road segments. These may be referred to 
as "aggregated-segment-significant" nodes. Every 
node in the geographic database at each of the layers 

55 is evaluated to determine whether it is an aggregated- 
segment-significant node. The nodes are evaluated one 
at a time, starting at the highest layer and working down. 
A node is "aggregated-segment-significant" at a given 



11 



BNSDOCID: <EP 0943895A2J_> 



19 



EP 0 943 895 A2 



20 



layer when only one road segment, or more than two 
road segments, are connected to it. However, it exactly 
two road segments are connected to a node, the node 
may not be aggregated-segment-significant. If a node 
is determined to be aggregated-segment-significant at 
a given layer, it is aggregated-segment-significant at all 
lower layers. Each road segment in a layer that has an 
aggregated-segment-significant node on one end and 
a non-significant node on the other end is a potential 
starting end for an aggregated segment. 
[0081] In Figure 10C. nodes N102 and N112 are ag- 
gregated-segment-significant since they connect to 
more than two segments. Nodes N104, N106, N107, 
N108, N109, and N113 may be non-significant since 
they connect to two and only two segments. Segment 
S1 is identified as a potential starting point for an aggre- 
gated segment since it has one node, Nil 2, that is ag- 
gregated-segment-significant and the other node N109 
that may be non-significant. Unless there is a condition, 
sign, or some other attribute change on S1. the node 
N 11 2 can be used as the starting point for an aggregated 
segment. The node N 109 on the other end of segment 
S1 is evaluated according to the applicable criteria to 
determine whether it is a significant node. If it is not a 
significant node, the node N109 is a potential internal 
node for an aggregated segment. Then, the other seg- 
ment connected to the node N109, i.e., S4 in Figure 
IOC, is evaluated (1) to determine whether its other 
node, N108, is aggregated-segment-significant, and (2) 
to check whether the other aggregation criteria are met. 
This process continues until an aggregated-segment- 
significant node is reached or until a node is reached 
that would othenwise be non-significant but which con- 
nects two segments that have differing conditions that 
disqualify them from being aggregated. These condi- 
tions are described above. If a node which would other- 
wise be non-significant connects two road segments 
having differing conditions that disqualify them from be- 
ing aggregated, the node is denominated as an aggre- 
gated-segment-significant node tor that rank and lower. 
[0082] It is noted that the above method produces an 
aggregated segnnent that has aggregated-segment-sig- 
nificant nodes at its ends and at least one non-significant 
node between the ends. However, not all aggregated- 
segment-significant nodes within a layer are necessarily 
located at end points of an aggregated segment. 

e. Location of appreciatecl segment records, 

[0083] Once a string of road segments (between two 
aggregated-segment-significant nodes) are identified 
that connect to each other by non-significant nodes, an 
aggregated segment record is created to represent this 
aggregation of road segments. In embodiments of geo- 
graphic databases in which the data are organized by 
type, the aggregated segment data records may be in- 
cluded among the routing data 136 as shown in Figure 
5. In embodiments of the geographic database in which 



the data are layered, the aggregated segment data 
records are found in layers above layer 0 (e.g., layer > 
0) as shown in Figure 6. In embodiments of geographic 
databases in which the data are spatially organized, ag- 
5 gregated segment data records may be included among 
the spatially organized data, such as in parcels 220 of 
the data shown in Figure 8. 

[0084] Figure 11 shows aggregated segment data 
records 422 stored in a parcel 220(7) of routing data 

10 1 36. The parcel 220(7) is in a layer greater than layer 0. 
With respect to Figure 11. the illustrated parcel 220(7) 
represents only one of a plurality of parcels within the 
layer > 0. Furthermore, it is understood that there may 
be one or more layers greater than layer 0, each with a 

is plurality of parcels, each including aggregated segment 
records- In a present embodiment, there are three layers 
greater than layer 0 (i.e., layers 1, 2, and 3) that include 
the arrangement of aggregated segment records illus- 
trated in Figure 11. In alternative embodiments, there 

20 may be more or fewer than three layers. 

f. The aaareaated segment entity, 

[0085] In one embodiment, the aggregated segment 
25 entity or record 422 includes all the same kinds of at- 
tribute Information that is included in non-aggregated 
road segment records (such as the road segment 
records 322 illustrated in Figure 9). Alternatively, the ag- 
gregated segment record 422 may include fewer of the 
30 kinds of attribute information that are included in non- 
aggregated road segment records 322. In one embodi- 
ment, each aggregated segment record 422 includes at- 
tribute information that corresponds to those features 
that adjacent road segments are required by the appli- 
35 cable criteria to have in common in order to form the 
aggregated segment record. The attributes that adja- 
cent segments are not required to have in common may 
be either combined or dropped in the process of gener- 
ating a single set of aggregated attributes for the aggre- 
40 gated segment record 422. 

[0086] The components of an aggregated segment 
record 422 are shown in Figure 12. The aggregated seg- 
ment record 422 includes a segment identifier (e.g., 
"ID") 423 that identifies it as an aggregated segment. 
45 The aggregated segment record 422 includes data that 
identifies its end nodes 424 and 425 which correspond 
to the aggregated-segment-significant nodes. (For ex- 
ample, referring to Figure 10D, it is noted that the ag- 
gregated segment AG12 includes nodes N102 and 
50 N1 1 2 that correspond to the end points of the aggregat- 
ed segment.) The aggregated segment record 422 may 
also store information about the aggregated segment 
that it represents including its length 430, its average 
speed 432, and a transit time 434. The aggregated seg- 
55 ment record 422 may also store additional information 
436. 

[0087] In a present embodiment, the aggregated seg- 
ment record 422 includes data that can be used to iden- 
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tify the segment records and node records that repre- 
sent the road segments and nodes between the road 
segments that in aggregation are represented by the ag- 
gregated segment record. The aggregated segment 
record 422 includes at least one pointer 426 to an array 5 
520 that includes abbreviated segment records 522 and 
abbreviated node records 523, In a present embodi- 
ment, the abbreviated records are stored sequentially 
in the array 520, that is, in order from one end (e.g., the 
left) of the aggregation to the other. In one embodiment, io 
the pointer 426 refers to the first record in the array 520. 
In the embodiment shown in Figure 12, the first record 
in the array 520 is a abbreviated segment record. The 
aggregated segment record 422 may also contains data 
435 that indicates a count of the number of abbreviated ^5 
segment records in the corresponding array 520 of ab- 
breviated segment and node records. Thus, these ab- 
breviated records 522 and 523 are accessible through 
the aggregated segment record through the pointer 426 
to the first abbreviated record and the count 435. 20 

g. Abbreviated segments and abbreviated node 
records, 

[0088] I n a present embodiment, when an aggregated 25 
segment record is formed, abbreviated data records are 
formed that represent the segments and nodes internal 
to the aggregated segment. Referring to Figures 11 and 
12, these abbreviated data records include abbreviated 
segment records 522 and abbreviated node records 30 
523. The abbreviated segment records 522 and abbre- 
viated node records 523 are associated with the aggre- 
gated segment record 422 and represent the nodes and 
segments that are represented in aggregation by the ag- 
gregated segment data record 422. These abbreviated 55 
records 522 and 523 are maintained in the geographic 
database in addition to the non-abbreviated segment 
records 322 that refer to the same road segment fea- 
tures and the non-abbreviated node records 323 that re- 
fer to the same node features. 40 
[0089] In a present embodiment, these abbreviated 
records 522 and 523 are maintained relatively close 
(physically and or logically) to the aggregated segment 
record 422 that refers to them. This enables the aggre- 
gated segment record to have relatively quick access to 
the information contained in the abbreviated segment 
records 522 and abbreviated node records 523. In one 
embodiment, the abbreviated records 522 and 523 are 
included in the same layer of data as the aggregated 
segment record that refers to them. Further, in a present so 
embodiment, in layers above layer 0 but below the high- 
est layer n, the abbreviated segment records 522 and 
abbreviated node records 523 are included in the same 
parcel as the aggregated segment record 422 that refers 
to them. This arrangement is Illustrated in Figure 11 55 
wherein the abbreviated segments 522 and the abbre- 
viated nodes 523 are included in the same parcel 220 
(7) as the aggregated segment 422 that refers to them. 



Within each of the parcels above layer 0. such as the 
parcel 220(7), th re may be a plurality of aggregated 
segment records 422, each of which refers to a plurality 
of abbreviated segment records 522 and abbreviated 
node records 523. 

[0090] When the abbreviated segments 522 and ab- 
breviated nodes 523 are included in the same parcel of 
data as the aggregated segment record 422 that refers 
to them, the reference 426 in the aggregated segment 
record 422 indicates the address or location of the ab- 
breviated segments 522 and abbreviated nodes 523 
within the parcel. This reference or pointer 426 may be 
in the form of an offset from a starting position of the 
parcel to the abbreviated segment and node records. 
Alternatively, any other suitable means of reference may 
be used. 

[0091] Referring to Figure 12, as mentioned above, in 
one embodiment, the abbreviated segment and node 
records are stored in the array 520, Within the array 520 
the abbreviated segment and node records alternate. 
The first record in the array pointed to by the aggregated 
segment record is an abbreviated segment record 522, 
followed by an abbreviated node record 523, followed 
by an abbreviated segment record 522, and so on, al- 
ternating until the last two records in the list are reached, 
which are an abbreviated node record 523 followed by 
an abbreviated segment record 522. This alternating ar- 
rangement of abbreviated segment and node records 
corresponds to the alternating arrangement of the phys- 
ical nodes and road segments that are represented in 
aggregation by the aggregated segment record. The 
first abbreviated segment record 522 in the array repre- 
sents the first segment encountered from an endpoint 
of an aggregated segment when traversing the aggre- 
gation represented by the aggregated segment record 
from an endpoint thereof. The next abbreviated record 
encounter is the first of the one or more internal nodes 
of the aggregated segment, starting from the same end- 
point of the aggregated segment. These abbreviated 
records alternate until the abbreviated segment imme- 
diately preceding the other endpoint of the aggregated 
segment is encountered. 

[0092] Referring to Figure 1 3, each abbreviated seg- 
ment record 522 contains a segment identifier 543 and 
data that indicate a length 544 and a transit time 545. In 
a present embodiment., the length 544 and a transit time 
545 of the abbreviated segment 522 are stored as a sin- 
gle fraction of the length 430 and transit time 434 of the 
aggi'egated segment record 422 that refers to them. The 
abbreviated segment record 522 may also contain ad- 
ditional information 548 by which the full (i.e., non-ab- 
breviated) version of the segment record (e.g., a seg- 
ment record 322) can be found. In one embodiment, this 
information 548 is a data flag which can be used as a 
reference to a layer 0 parcel identification, as explained 
below. The abbreviated segment record 522 may also 
contain additional information 549, such as the bearing 
of the road segment represented by the abbreviated 
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segment, although such information may be accessed 
from the referenced layer 0 data record 322 instead. 
[0093] Referring to Figure 14. each abbreviated node 
record 523 contains an abbreviated node identifier ("ID") 
553 and data that identifies its position 554. The abbre- 
viated node record 523 may also contain additional in- 
formation, such as a pointer or reference 559, by which 
the full (i.e. . non-abbreviated) version of the node record 
323 can be found. The abbreviated node record 523 
may also contain additional information 555. 
[0094] As mentioned above, the abbreviated segment 
and node records include references to the non-abbre- 
viated versions of these records. These references may 
be used to obtain information that is unavailable in the 
abbreviated segment and node data records, but is in- 
cluded in the non-abbreviated versions of these records. 
For example, the non-abbreviated versions of these 
records are used when the calculated route is complete 
and cross-references to the other data types, such as 
the map display type and the maneuver type, are re- 
quired. In the abbreviated segment record 522, the ref- 
erence 548 is a data flag that indicates whether the ab- 
breviated segment record 522 contains a parcel ID in- 
dex. (The reference 559 in the abbreviated node record 
523 may include a sinnilar data flag.) If an abbreviated 
segment or node record contains a parcel I D index field, 
then that abbreviated segment or node record has that 
parcel ID at layer 0. However, if an abbreviated segment 
or node record does not contain a parcel ID index, then 
the node is assumed to have the layer 0 parcel ID of the 
preceding abbreviated node (or segment) record that 
did contain a parcel ID field. In this way. if the layer 0 
entities referenced by successive abbreviated records 
are located in the same parcel, the parcel ID number is 
not required to be repeated for each successive abbre- 
viated record. 

/?. Upward Referencing. 

[0095] In a present embodiment, each of the segment 
records 322 in layers less than layer n includes data that 
identifies each of the aggregated segment records 422 
in each of the higher layers that represent an aggrega- 
tion of road segments that includes the road segment 
represented by the segment record 322. A diagram il- 
lustrating this feature of the segment data record 322 is 
included in Figure 1 5. As shown in Figure 15, in addition 
to the other types of attributes included in the segment 
data record 322, there is a reference 648 to each of the 
aggregated segment records 422 in higher layers that 
represents aggregations of road segments that include 
the road segment represented by the segment record. 
In a present embodiment, the reference 648 in the seg- 
ment record 322 identifies the aggregated segment 
records by aggregated segment ID 423 (in Figure 12) 
and layer (i.e., 1 through n) in which the aggregated seg- 
ment record appears. This information is in addition to 
the other information included in the segment data 



record 322. 

IV ALTERNATIVE EMBODIMENTS 

5 a. Separation of aaareaated and abbreviated records 

[0096] In a present embodiment, for some layers of 
routing data above layer 0, the abbreviated segment 
records 522 and abbreviated node records 523 are 
10 stored in the same parcel as the aggregated segment 
record 422 that refers to them, as described above. 
However, according to a present embodiment, in at least 
one layer of routing data above layer 0, the abbreviated 
segment records and abbreviated node records are 
15 stored in a separate parcel from the parcel that contains 
the aggregated segment record that refers to them. Spe- 
cifically, in one present embodiment, for the highest lay- 
er (i.e.. layer n. where n=4), the abbreviated segment 
and abbreviated node records are stored in a separate 
20 parcel from the parcel that contains the aggregated seg- 
ment record that refers to them. This latter arrangement 
is shown in Figure 16. As shown in Figure 16, the ab- 
breviated segment records 522 and abbreviated node 
records 523 are stored in a parcel 220(3) that is separate 
25 from the parcels 220(1 ), 220(2).. that contain the aggre- 
gated segment records 422 that refer to them. In a 
present embodiment, this parcel 220(3) of abbreviated 
records contains abbreviated segment records 522 and 
abbreviated node records 523 (and possibly some ad- 
30 ditional information, such as header information). How- 
ever, the parcel 220(3) containing the abbreviated 
records does not include any routing data. As illustrated 
in Figure 16, the abbreviated records 522 and 523 are 
included in the same layer (i.e., layer n) as the aggre- 
ss gated segment records 422 that refer to them. In an al- 
ternate embodiment, the parcel 220(3) of abbreviated 
segment records 522 and abbreviated node records 523 
may be located in another layer or elsewhere in the da- 
tabase. 

40 [0097] As with the aggregated segment records that 
are included in the layers below layer n, each aggregat- 
ed segment record Includes a pointer or other suitable 
reference to the abbreviated segment and node records 
that represent the features represented in aggregation 

45 by the aggregated segment record. Figure 1 7 illustrates 
the components of an aggregated segment record and 
its referenced abbreviated segment and node records 
according to the embodiment shown in Figure 16. The 
aggregated segment record 422 includes at least one 

50 pointer 426 to an array 520 that includes abbreviated 
segment records 522 and abbreviated node records 
523. In this embodiment, the pointer 426 refers to the 
first record in the array 520. Because the abbreviated 
records are stored in a separate parcel from the aggre- 

ss gated segment records that refer to them, the reference 
426 in an aggregated s gment record 422 to its associ- 
ated abbreviated segment and node records 522, 523. 
includes an appropriate identification of the parcel in 
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which the abbreviated records are located. As in the ar- 
ray 520 described In connection with Figure 12, the ab- 
breviated records are stored sequentially in the array 
520 in order from one end of the represented aggrega- 
tion to the other However, unlike the embodiment 
shown in Figure 12, when the abbreviated records are 
in a separate parcel from the parcel that contains the 
aggregated segment record that refers to them, the first 
record in the array 520 is an abbreviated node record 
523, followed by an abbreviated segment record 522, 
and so on, alternating until the last two records in the 
list are reached, which are an abbreviated segment 
record 522 followed by an abbreviated node record 523. 
When the abbreviated records are in a separate parcel 
from the parcel that contains the aggregated segment 
record that refers to them: the first record in the array 
520 is an abbreviated node record 523 which represents 
one of the end points of the referencing aggregated seg- 
ment record and the last record in the array 520 is an 
abbreviated node record 523 which represents the other 
end point of the referencing aggregated segment 
record. It is useful to have these aggregated node 
records 523 that represent the aggregated segment end 
points in the array 520 when the abbreviated records 
are located in a separate parcel from the aggregated 
segment record 422 that refers to them because other- 
wise there may not be records in the parcel containing 
the abbreviated records that represent these end points 
of the aggregated segment. In other respects, the ag- 
gregated segment records 422 and abbreviated records 
522. 523, in layer n are similar to those in the previously 
described embodiment. 

[0098] The abbreviated segment records 522 and the 
abbreviated node records 523 in the layer n parcel 220 
(3) include appropriate references to corresponding 
non-abbreviated segment and node records contained 
in the parcels 220(4) and 220(5) in layer 0 that represent 
the same corresponding geographic features. As de- 
scribed in connection with the previous embodiment, if 
the information included in the non-abbreviated seg- 
ment or node records is needed for a navigation func- 
tion, the references included in the abbreviated segment 
and node records contained in the layer n abbreviated 
record parcel 220(3) can be used to find the correspond- 
ing non-abbreviated segment and node records in the 
layer 0 parcels 220(4) and 220(5) (illustrated in Figure 
16). 

[0099] Separating the abbreviated segment and ab- 
breviated node records from the aggregated segment 
record that refers to them has the effect of allowing the 
routing parcels that contain the aggregated segment 
records to hold more routing data other than the abbre- 
viated segment and node record data. This allows the 
parcels of routing data that contain the aggregated seg- 
ment records to represent geographic features that are 
encompassed within larger sized rectangular areas. 
Therefore, fewer such parcels of routing data are need- 
ed when calculating a route across the geographic area 



thereby generally enhancing navigation system per- 
formance for some types of functions such as route cal- 
culation. 

[0100] (According to this alternative embodiment, the 
s abbreviated records are separated from the aggregated 
records that refer to them only in the highest layer (i.e., 
layer n, where n=4) of data. In another version of this 
alternative embodiment, the abbreviated records may 
be separated from the aggregated records in other lay- 
10 ers as well. According to still another version of this al- 
ternative embodiment, the abbreviated records may be 
separated from the aggregated records that refer to 
them in all the layers of data in which aggregated 
records are present.) 

15 

b. Interleaving of data types 

[0101] As previously mentioned, storing the abbrevi- 
ated records separately from the routing data that in- 

20 eludes the aggregated segment records that refer to 
them can provide certain advantages that enhance nav- 
igation system performance. Further advantages can be 
obtained in an embodiment wherein the routing data 
(that include the aggregated segment data records) are 

25 interleaved with the abbreviated records. This may re- 
duce the search and access times for data when per- 
forming certain kinds of navigation functions and there- 
by possibly further enhance navigation system perform- 
ance. Specifically, in this further alternative embodi- 

30 rnent, the parcels that contain the routing data that in- 
clude aggregated segment data records are interleaved 
with the parcels that contain the abbreviated records 
that are referenced by the aggregated segment records 
within the same layer. 

35 [0102] Figures 18, 19, and 20 show three different 
ways that parcels containing routing data (including ag- 
gregated segment records) and parcels that contain ab- 
breviated record data (which are referenced by the ag- 
gregated segment records) can be arranged within a 

40 layer. For purposes of this embodiment, the interleaving 
of abbreviated record data with routing data within a lay- 
er is described. The advantages that result from inter- 
leaving different data types, and in particular parcels of 
different data types, are not limited to just routing data 

45 and abbreviated record data. It is understood that the 
disclosed concepts can be extended to other types and 
layers of data as well, as described below. Therefore, 
various navigation functions can benefit from the per- 
formance enhancements associated with interleaving 

50 data types. 

[01 03] Figure 1 8 shows a plurality of parcels 220 with- 
in a layer n of routing data. These parcels include par- 
cels that include routing data (labeled with an "R") and 
parcels that include abbreviated segment and node 

55 records (labeled with an "A"), The routing parcels con- 
tain aggregated segment records that include referenc- 
es to the abbreviated segment and node records that 
represent, individually, the road segments and end- 
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points thereof that the aggregated segment records rep- 
resent in aggregation. In the embodiment shown in Fig- 
ure 18. even though all the parcels that contain abbre- 
viated segment and node records are located in the 
same layer of routing data as the routing parcels that 
include the aggregated segment records that refer to 
them, all the parcels that contain the abbreviated seg- 
ment and node records are located and stored apart 
from (i.e., before or after) all the parcels that contain the 
layer n routing parcels that include the aggregated seg- 
ment records that refer to them. As mentioned above, 
placing the parcels that contain the abbreviated seg- 
ment and node records in the same layer as the parcels 
that contain the aggregated segment records that refer 
to them affords the advantage that generally less time 
is required to access the abbreviated records when they 
are referenced by the aggregated segment records, 
thereby leading to improved navigation system perform- 
ance. 

[0104] Although the embodiment shown in Figure 18 
provides potential performance advantages, still further 
advantages can be obtained if the parcels containing the 
abbreviated segment records are placed even closer to 
the parcels containing the aggregated segment records 
that refer to them. The embodiment shown in Figure 1 9 
shows an arrangement of parcels that affords this ad- 
vantage. In the embodiment of Figure 19, following each 
parcel of routing data is a parcel containing abbreviated 
records. The abbreviated records in each parcel of ab- 
breviated records are referenced by the aggregated 
segment records in the immediately adjacent parcel. (In 
Figure 19, the parcel containing the abbreviated seg- 
ment and node records is shown immediately following 
the parcel that contains the routing data records that inc! 
ude the aggregated segment records that refer to them. 
In an alternative embodiment, the parcel containing the 
abbreviated segment and node records can immediate- 
ly precede the parcel that contains the routing data 
records that include the aggregated segment records 
that refer to them.) 

[0105] The arrangement shown in Figure 1 9 may af- 
ford even further advantages over the embodiment 
shown in Figure 18 for certain functions. Because the 
parcel containing the abbreviated segment and node 
records is immediately adjacent to the parcel containing 
the routing data that includes the aggregated segment 
records that refer to them, even less time may be re- 
quired to access the abbreviated records when they are 
referenced by the aggregated segment records, thereby 
leading to even further improved navigation systenn per- 
formance, 

[0106] A disadvantage associated with the arrange- 
ment shown in Figure 19 is that the amount of data as- 
sociated with the abbreviated segment and node 
records referenced by the aggregated segment records 
in a single parcel of routing data does not necessarily 
conform to an ideal parcel size. If the routing parcel con- 
tains relatively few aggregated segment records or ag- 



gregated segment records that represent aggregations 
of relatively few segments, there will be a correspond- 
ingly few abbreviated records in the adjacent parcel of 
abbreviated records. Similarly if the routing parcel con- 

5 tains relatively many aggregated segment records or 
aggregated segment records that represent aggrega- 
tions of relatively many segments, there will be a corre- 
spondingly many abbreviated records in the adjacent 
parcel of abbreviated records. In the embodiment of Fig- 

10 ure 19, the data size requirement for the abbreviated 
segment and node records referenced by the aggregat- 
ed segment records in each single parcel of routing data 
depends upon the number and kind of aggregated seg- 
ment records in the parcel of routing data. In turn, the 

IS number and kind of aggregated segment records in a 
parcel of routing data depends, at least to some extent, 
on the represented road network. Since road networks 
can be relatively variable, the data size requirements for 
the abbreviated segment and node records referenced 

20 by the aggregated segment records in a single parcel of 
routing data can also vary considerably. 
[0107] In general, the abbreviated segment and node 
records referenced by the aggregated segment records 
in a parcel require less than, and sometimes consider- 

25 ably less than, an ideal parcel size. This means that in 
the embodiment shown in Figure 19, substantial pad- 
ding may be required to be added the abbreviated 
record data in some parcels of abbreviated records to 
maintain a uniform parcel size among the parcels within 

30 the layer. This has the result that the parcels that contain 
the abbreviated records may be less than a desired fill 
percentage. If a desired parcel fill percentage is 80%. 
some of the parcels that contain abbreviated segment 
and node records may be less than 50% or even less 

35 than 20% full. It is generally undesirable to have parcels 
substantially less than full. One reason that less than 
full parcels is undesirable is that data storage space is 
wasted that could otherwise be used to store information 
that can be valuable to the end-user. Another undesira- 

40 ble effect of having parcels that are substantially less 
than full is increased fragmentation of the database. 
This can result in increased search and access times 
leading to poor performance. 

[01 08] Another potential disadvantage of the embod- 
45 iment of Figure 19 is that under some circumstances, 
the data requirements for the abbreviated segment and 
node records referenced by the aggregated segment 
records in a single parcel of routing data may exceed 
the maximum parcel size. 
so [0109] With respect to the embodiment in Figure 1 9, 
it is possible to make the parcels containing abbreviated 
segment and node records smaller (or larger) in size 
than the immediately adjacent parcels that contain the 
routing data that include the aggregated segment 
55 records that to refer to them. However, making the par- 
cels containing the abbreviated segment and node 
records different sizes than the parcels containing the 
routing data does not reduce fragmentation. Further- 
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more, since the factors used to determine a desired par- 
cel size may include specific characteristics of the media 
upon which the data are stored, there are relatively few 
available preferred sizes in which a parcel can be pro- 
vided in order to obtain the desired performance char- 
acteristics. 

[0110] Thus, although the interleaving arrangement 
shown in Figure 1 9 may provide performance advantag- 
es in navigation systems for some datatypes, it may not 
be suitable for other data types. With respect to the em- 
bodiment of interleaved data types shown in Figure 1 9, 
it is best suited for types of data in which the parcel sizes 
of the different data types can be balanced readily. 
[0111] Figure 20 shows another arrangement for in- 
terleaving parcels of abbreviated segment and node 
records with parcels containing routing data that include 
the aggregated records that reference abbreviated seg- 
ment and node records. In Figure 20, the parcels that 
contain abbreviated segment and node records are 
formed to have a size that conforms to a desired parcel 
size and are formed to have a generally high fill percent- 
age. In one embodiment, the parcels containing abbre- 
viated segment and node records may have the same 
size as the routing data parcels that contain the aggre- 
gated segment records that refer to them. For example, 
if the routing data parcels are provided in a 1 6 K size, 
the parcels containing the abbreviated segment and 
node records may also be provided in sizes of 16 K 
each. Other sizes are suitable. 

[0112] In Figure 20, the parcels containing routing da- 
ta are interleaved with the parcels containing the abbre- 
viated segment and node records. In a present embod- 
iment, each parcel that contains abbreviated segment 
and node records is grouped together with the one or 
more routing parcels that contain the aggregated seg- 
ment records that refer to them. In one embodiment, the 
parcel that contains the abbreviated segment and node 
records that are referenced by aggregated segment 
records contained in one or more routing parcels are lo- 
cated immediately after these routing parcels. In an al- 
ternative embodiment, the parcel that contains the ab- 
breviated segment and node records that are refer- 
enced by aggregated segment records contained in one 
or more routing parcels may be located immediately be- 
fore these routing parcels. In a preferred embodiment, 
the placement of the parcel that contains the abbreviat- 
ed records depends upon the spatial organization of the 
data within the layer, as described further below. 
[0113] Referring to Figure 20. four layer n parcels con- 
taining routing data are followed by one parcel contain- 
ing abbreviated segment and node records. The one 
parcel containing abbreviated segment and node 
records contains all the abbreviated segment and node 
records referenced by all the aggregated segment 
records contained in the four routing data parcels that 
immediately precede it. In Figure 20, following the first 
abbreviated record parcel are two more routing parcels 
followed by another parcel containing abbreviated 



records. This second parcel of abbreviated records con- 
tains the abbreviated records referenced by the aggre- 
gated segment records contained in the two routing par- 
cels immediately preceding it. In the embodiment shown 
5 in Figure 20, the number of parcels of routing data and 
the number of parcels of abbreviated records are deter- 
mined in order to (1 ) maintain a desired parcel size and 
fill percentage among the parcels in the layer, and (2) 
maintain the spatially parcelized routing parcels close 
to the spatially parcelized abbreviated record parcels 
that represent the same geographic features. The em- 
bodiment shown in Figure 20 combines the advantage 
that the abbreviated segment and node records are 
stored relatively close to the aggregated segment 
records that refer to them with the advantage that all the 
parcels conform generally to a desired parcel size and 
fill percentage. 

c. Process for forming interleaved data 

[0114] As noted above, in a preferred embodiment the 
routing parcels are spatially parcelized, and likewise the 
parcels containing the abbreviated segment and node 
records are spatially parcelized. In a preferred embodi- 
ment, the parcels containing the abbreviated segment 
and node records are parcelized in parallel with the rout- 
ing data parcels with which they are interleaved. A proc- 
ess for forming the interleaving arrangement is de- 
scribed below. 

[0115] Processes for forming a geographic database 
including layered parcelized routing data are disclosed 
in Ser. Nos. 08/924,328. 08/935,809. and 08/740.295, 
the entire disclosures of which are incorporated by ref- 
erence herein. Briefly, one process for forming a layered 
parcelized geographic database having at least one in- 
terleaved portion is illustrated in Figure 21. (In Figure 
21 , the general Steps of the process are shown on the 
left and the corresponding component parts used in the 
Steps are shown on the right.) 

[0116] Starting with a geographic database 900 that 
is provided in a generalized data format, separate inter- 
mediate format files 902 for each data type and layer 
are formed (at Step A). The generalized data format ge- 
ographic database 900 may be in a proprietary format 
or in a n on -proprietary format. In the generalized data 
format geographic database file 900, the geographic da- 
ta may be undifferentiated as to type and layer These 
intermediate format files 902 formed from the general- 
ized data format database file 900 are created in, order 
to derive each of the different types of data, such as rout- 
ing, cartographic, point-of-interest. maneuver, and so 
on, as shown in Figure 5, as well as to derive each of 
the layers of some of these types, as shown in Figure 6. 
[0117] After each of these separate intermediate for- 
mat files 902 is created, each of these intermediate for- 
mat files 902 is parcelized to form parcels 906 of data 
records of each data type for each layer (at Step B). Dif- 
ferent kinds of parcelization processes can be used, in- 
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eluding different kinds of processes for spatial parceli- 
zation. as described above. As the parcels 906 for each 
of the separate types and layers are formed, the parcels 
906 for each layer and type are concatenated into a sin- 
gle file 910 (at Step C). With respect to a portion of the 
concatenated file 910 in which parcels are interleaved, 
the parcelsfrom the two or more parcelized intermediate 
files 906 are selected and interleaved (at Step D), as 
described in more detail below. 

[0118] As the separate parcels 906 for each of the 
separate types and layers are formed, parcel identifica- 
tions are assigned. After all the separate parcels 906 for 
each of the separate types and layers are concatenated 
into a single file 910 and parcel identifications are as- 
signed, parcel references throughout all the data 
records and indices are updated to reflect the new as- 
signed parcel identifications to form a final format file 
912 (at Step E). 

[01 1 9] These general steps for forming a geographic 
database represent only one way that a geographic da- 
tabase can be formed and it is understood that there are 
other methods for iForming a geographic database that 
incorporates the interleaving of different types of data. 
A more detailed description of aspects of the process 
for forming a geographic database having an inter- 
leaved portion is described as follows. 
[0120] According to one embodiment, to form a geo- 
graphic database that interleaves different types of data, 
a separate intermediate file is formed for each of the 
different types of data that are to be interleaved. For ex- 
ample, in order to form a geographic database that in- 
cludes parcels that contain routing data including aggre- 
gated segment records and separate parcels that con- 
tain abbreviated segment and node records referenced 
by the aggregated segment records (as shown in Fig- 
ures 17-20), separate intermediate format files are 
formed for the routing data and for the abbreviated seg- 
ment and node data. The separate intemnediate format 
file for the abbreviated records contains the portions of 
the generalized data format geographic database file 
that are necessary to derive the abbreviated segment 
and node records (such as the records 522 and 523 in 
Figures 13 and 14, respectively). 
[0121] If parcels containing abbreviated records are 
to be interleaved with parcels that contain routing data 
in more than one layer, separate intermediate format 
files of abbreviated segment and node records are 
formed for each separate layer In a present embodi- 
ment, the abbreviated segment and node records are 
stored in separate parcels from the aggregated segment 
and node records that refer to them only in the highest 
layer (i.e., layer n, where n=4) of the routing data. How- 
ever, in alternative embodiments, abbreviated segment 
and node records may be stored in separate parcels 
from the aggregated segment and node records that re- 
fer to them in any layer that contains aggregated seg- 
ment records. 

[0122] In addition, in further alternative embodiments. 



if parcels of data types other than routing data and ab- 
breviated records are to be interleaved, intermediate 
format files of these different data types are formed, as 
necessary. 

5 [0123] Once the intermediate format files for each lay- 
er of routing data and each layer of abbreviated segment 
and node records are formed, each of these intermedi- 
ate format files is parcelized. In a preferred embodiment, 
routing data layer 0 is parcelized first. Alternatively an- 

10 other of the types of data, such as the cartographic data 
or the maneuver data, may be parcelized first. In 
parcelizing the routing layer 0 data, any suitable parceli- 
zation method can be used, such as any of the parceli- 
zation methods disclosed in Ser. Nos. 08/924,328, 

15 08/935,809, and 08/740,295, the entire disclosures of 
which are incorporated by reference herein. 
[0124] After the routing layer 0 data are parcelized, 
the higher layers of routing data are parcelized. In a pre- 
ferred embodiment, the higher layers of routing data are 

20 parcelized in parallel with the parcelization method used 
for routing layer 0 data. This means that when forming 
parcels for a higher layer of routing data, the same 
boundaries that were defined in the process of deter- 
mining the rectangular areas associated with the routing 

25 layer 0 parcels are used to define the rectangular areas 
associated with each higher layer parcel . Of course, 
since higher layers of data include fewer records, higher 
layer parcels may be associated with larger rectangular 
areas. However, if any higher layer parcel is a3sociated 

30 with a larger rectangular area than a lower layer parcel, 
the larger rectangular area associated with a higher lay- 
er parcel will exactly encompass the smaller rectangular 
areas associated with two or more lower layer routing 
data parcels, 

35 [0125] After the intermediate format file representing 
a layer of routing data having aggregated segments is 
parcelized, the intermediate format data file containing 
th e abbreviated segment and node records for the same 
layer is parcelized. (Note that the intermediate data file 

40 containing the abbreviated segment and node records 
can be parcelized immediately after the layer of routing 
data are parcelized, or alternatively, the intermediate 
data file containing the abbreviated segment and node 
records can be parcelized after other types or layers of 

45 data are parcelized.) In a preferred embodiment, the in- 
termediate data file containing the abbreviated segment 
and node records is parcelized in parallel with the rout- 
ing data. The parallel parcelization of an intermediate 
format file containing abbreviated segment and node 

50 records is similar to the parallel parcelization of interme- 
diate format files of higher layers of routing data, as de- 
scribed above. Thus, the same boundaries that were de- 
fined for the rectangular areas associated with the rout- 
ing layer 0 parcels are used, to the extents necessary, 

55 to define rectangular areas associated with parcels of 
the abbreviated segment and node records. Thus, a rec- 
tangular area associated with a parcel of abbreviated 
segment and node records either corresponds exactly 
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to the rectangular area associated with the routing data 
parcel that includes the aggregated segment records 
that will refer to the abbreviated segment and node 
records or corresponds exactly to two or more rectan- 
gular areas associated with the two or more routing data 5 
parcels that include the aggregated segment records 
that refer to the abbreviated segment and node records. 
This arrangement is illustrated graphically in Figure 22. 
(In the event that the abbreviated records referenced by 
the aggregated segment records in a parcel of routing 
data comprise a substantially larger amount of data than 
the routing parcel, the opposite relationship will apply, 1. 
e., the rectangular areas associated with two or more 
abbreviated records parcels will exactly encompass the 
rectangular areas associated with a single routing par- 
cel.) 

[0126] Figure 22 shows a map 612 of a portion of a 
geographic region. The region is overlaid with a plurality 
of boundary lines. These boundary lines are selected 
according to a parcelization method in order lo deter- 20 
mine a plurality of rectangular areas. As mentioned 
above, any suitable parcelization method may be used. 
The boundaries forming each of the rectangular areas 
are selected so that each rectangular area encompass- 
es geographic features that are represented by geo- 2S 
graphic data records contained within a separate parcel 
for a given layer and type of data. In Figure 22, the 
boundaries define the rectangular areas that encom- 
pass geographic features represented by routing data 
records contained in separate parcels of routing layer 0 50 
data (It is understood that Figure 22 shows just a portion 
of a geographic region. In a geographic region repre- 
sented by a geographic database, such as the geo- 
graphic database 40 used with a navigation system 10 
in Figure 1 , there nnay be hundreds of such rectangular 3S 
areas, each associated with a separate parcel of routing 
layer 0 data.) 

[01 27] When fornning parcels of abbreviated segment 
and node records, the boundary lines previously defined 
for the routing layer 0 data are used to define the rec- ^0 
tangular areas that encompass the abbreviated seg- 
ment and node records to be contained in each parcel. 
In a present embodiment, these abbreviated segment 
and node records have relatively smaller data size re- 
quirements than the routing data for a corresponding ar- ^5 
ea. Therefore, parcels formed of abbreviated segment 
and node records may represent larger rectangular 
sized areas. However, since the boundary lines to be 
used when defining a rectangular area associated with 
a parcel are constrained to those previously defined for 50 
routing layer 0 data, a rectangular area associated with 
a parcel of abbreviated segment and node records in- 
cludes entire rectangular areas associated with routing 
layer parcels. For example, in Figure 22, if the abbrevi- 
ated segment and node records that represent the fea- 
tures contained in the four rectangular areas 650(1 ), 650 
(2), 650(3), and 650(4) are less than a maximum parcel 
size, a parcel of all these abbreviated segment and node 



records can be formed. Similarly, if the abbreviated seg- 
ment and node records that represent the features con- 
tained in the two rectangular areas 650(5) and 650(6) 
are less than a maximum parcel size, a parcel can be 
formed of these abbreviated segment and node records. 
[01 28] After parcelization, the intermediate format file 
contains the parcelized abbreviated segment and node 
records in a plurality of parcels. Each parcel is padded 
to a desired size. The parcels are arranged in an order 
that reflects the spatial organization of the data. 
[0129] Once the intermediate format file containing 
the routing data for layer n is parcelized and the inter- 
mediate format file containing the abbreviated segment 
and node data for layer n is parcelized, the parcels of 
the two intermediate format files of different data types 
can be interieaved. The intermediate format files to be 
interleaved are identified to a compiler or other process 
that forms the final format geographic database file. The 
identified files are input into the compiler or other pro- 
gram or process. (In a present embodiment, the compil- 
er also receives as input the layers and types of data 
that are not going to be Interleaved.) 
[0130] As illustrated in Figure 21, in forming the final 
format geographic database file, the portion of the file 
that contains interleaved parcels of different data types 
may be included among other portions that include non- 
interleaved parcels, if any. For example, the compiler 
may store the non-interleaved parcels of routing layer 
data 0. followed by the non-interleaved parcels of rout- 
ing layer 1, and so on. When the compiler gets to an 
interleaved layer, (e.g., layer n routing data), both the 
parcelized intermediate format file containing routing 
layer n data and the parcelized intermediate format file 
containing the layer 4 abbreviated records are present. 
In forming the final format geographic database file, the 
spatial organization of the routing data and abbreviated 
record data in the interleaved layer is maintained. To fa- 
cilitate maintaining the spatial organization of the data 
a kd-tree is used during the interleaving process. Figure 
23 shows a kd-tree representing the parcels formed of 
the data encompassed within the rectangular areas of 
Figure 22. In a preferred embodiment, a kd-tree is 
formed during the parcelization of the routing layer 0 da- 
ta. An entry or node in the kd-tree is associated with 
each "cut" (i.e., division) of an encompassing rectangu- 
lar area which is made when forming the individual 
smaller rectangular areas associated with each of the 
parcels of routing layer 0 data. Each leaf node (i.e., a 
node with no children nodes) of the kd-tree represents 
one of the routing layer 0 parcels. Therefore, a layer 0 
parcel can be found using this kd-tree. (A form of the kd- 
tree can be stored as a file and used as search tool in 
finding data spatially within the parcels, as known to 
those of skill in the art.) Each parcel (such as a higher 
layer parcel or a parcel of abbreviated records) which is 
formed without making all the cuts required for the layer 
0 parcels is represented by one of the internal nodes of 
the kd-tree. 
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[0131] The kd-tree formed when parcelizing the rout- 
ing layer 0 data can also be used when interleaving the 
parcels of routing data and the parcels of abbreviated 
record data (as illustrated at Step D in Figure 21). The 
rectangular areas associated with the parcels of layer 4 
routing data and parcels of abbreviated record data do 
not necessarily share the exact same boundaries (i.e., 
in Figure 22) as the rectangular areas associated with 
the parcels of layer Grouting data that were used to form 
the kd-tree. Moreover, the rectangular areas associated 
with the parcels of abbreviated records do not neces- 
sarily share the exact same boundaries as the rectan- 
gular areas associated with the parcels of routing layer 
4 data. However, the cuts used to form the layer 4 rout- 
ing parcel boundaries and the abbreviated record parcel 
boundaries are included In the kd-tree, since these cuts 
were made in the process of forming the routing layer 0 
parcels. Accordingly, when interleaving these different 
types of data, the kd-tree can be used to spatially or- 
ganize the parcels of these different types of data. The 
nodes of the kd-tree are traversed in order. As each 
node of the kd-tree is encountered in order, if a routing 
layer 4 parcel or an abbreviated record parcel was 
formed by the cut associated with the kd-tree node, the 
parcel (routing or abbreviated record or both) is added 
to the portion of the final format file corresponding to the 
routing layer 4 data. By traversing the kd-tree in order, 
the routing layer 4 parcels and abbreviated record par- 
cels associated with the same geographic features can 
be identified and grouped together in the portion of the 
final format file corresponding to routing layer 4. In this 
manner, since the abbreviated records represent the 
same geographic features as the aggregated segment 
records that refer to them, by using the represented ge- 
ographic features, the abbreviated segment records can 
be placed close to the aggregated segment records that 
refer to them. 

[01 32] After the routing data parcels and abbreviated 
records parcels are interleaved, they can be concate- 
nated with the parcels of other types and layers into the 
final format file. Parcel identification numbers are as- 
signed and parcel references within each parcel are up- 
dated, as necessary to form the final format file 912 (in 
Step E of Figure 21). 

V. OPERATION 

a. Rank suppression 

[0133] The disclosed embodiments facilitate using 
the geographic database thereby providing the potential 
for improved navigation system performance. The dis- 
closed embodiments may be used with different kinds 
of navigation systems and may be employed in systems 
that employ different search routines or algorithms for 
determining a route between an origin and a destination 
in the geographic region. These search routines may dif- 
fer in the manner in which they use the geographic data 



to calculate a route. One way that a route search routine 
uses the geographic data to calculate a route is to eval- 
uate alternative potential routes from points between the 
origin and destination to determine which one is most 
5 promising to form part of an optimal route between the 
origin and destination. For example, a route searching 
routine uses the geographic data to evaluate some or 
all of the successor road segments leading from an in- 
tersection point between the origin and destination to 
10 determine which successor road segment is the most 
promising based upon some criteria, such as distance, 
time, etc. This evaluation of successor road segments 
can be relatively time consuming. This is one of the rea- 
sons why the road segment records are assigned a rank 
15 in the geographic database and why the road segment 
records may be provided in a plurality of layers based 
upon rank. Using higher layers provides an advantage 
for route calculation purposes since higher layers in- 
clude fewer road segment records that can be evaluated 
20 from each intersection. Using aggregated segment 
records also provides advantages by reducing the 
number of segments or nodes that can be evaluated. 
[01 34] When a route calculation program determines 
a route, the calculated route is formed of a listing of road 
25 segment records that represent the individual road seg- 
ments that constitute the route. Each consecutive pair 
of road segments in the calculated list shares a common 
node, thereby ensuring the integrity of the route. 
[0135] When a route calculation program calculates 
30 a route, it may initially use layer 0 data. This may be 
necessary because the starting point or the destination 
of a route is not necessarily located on a higher ranked 
road. Higher layers of the geographic database may be 
used when calculating portions of the route away from 
35 the starting location or destination location, i.e.. along 
the middle portion of the route. As stated above, a valid 
route includes a listing of segments wherein consecu- 
tive segments share a common node between them. 
Therefore, when segments acquired from a higher layer 
40 of the database are used in a route they are "entered" 
from their end points. When a valid route includes seg- 
ment records acquired from different layers, the point 
along the route at which higher layer data can be used 
is limited to those positions that correspond to an end 
45 point of a segment in the higher layer. (The endpoints 
of segments in higher layers are necessarily also locat- 
ed In lower layers). This means that before a route cal- 
culation program can take advantage of the higher lay- 
. ers, it has to evaluate nodes and segments in a lower 
so layer in order to find an intersection in the lower layer 
that corresponds to an end point of a segment in the 
higher layer to which the jump to the higher layer can 
be made. 

[0136] In the layer in which they are present, aggre- 
55 gated segment records replace the individual road seg- 
ment records that represent the same road segments 
for route calculation purposes. Thus, the internal nodes 
of aggregated segments are not available as endpoints 
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of valid segments at the layer at which the aggregated 
segment records are present. It follows therefore that 
the internal nodes of aggregated segments are not 
available as locations from which a route calculation 
program can switch from a lower layer to the higher lay- 
er. The presence of aggregated segments in a layer re- 
duces the number of locations at which a route calcula- 
tion program can switch into the layer from a lower layer. 
When an aggregated segment record represents a rel- 
atively large aggregation of road segments, it includes 
a correspondingly targe number of internal nodes which 
are no longer available as places at which a switch to 
the higher layer can be made. 

[0137] To improve navigation system performance, a 
function call is provided that can be used when the suc- 
cessors of a segment record in a layer below the highest 
layer n of data are being evaluated. The function call 
returns the end points of any aggregated segment 
record in any higher layer that represents an aggrega- 
tion of segments that includes the segment represented 
by the road segment record in the lower layer. Use of 
this function call is facilitated because each road seg- 
ment record in each layer below layer n includes data 
(648 in Figure 17) that identifies each of the aggregated 
segment records in each of the higher layers that rep- 
resents an aggregation of road segments that includes 
the road segment represented by the segment record 
from which the function call is nnade. Using these data 
648 (which in a present embodiment includes the ag- 
gregated segment ID and layer), the parcels that contain 
the aggregated segment records can be identified and 
accessed. Each of these parcels is loaded, and the data 
in each of the aggregated segment records can be eval- 
uated. Specifically, the data that identify the end points 
of each aggregated segment are returned. This infor- 
mation can be obtained for each of the higher level ag- 
gregated segment records that represents an aggrega- 
tion that includes the segment represented by the seg- 
ment record in the lower layer. Then this information can 
be evaluated for route searching purposes. Specifically, 
the information can be used to determine whether it 
would be advantageous to incorporate into a route being 
calculated that portion to either of its end points of any 
aggregation represented in any higher layer. The eval- 
uation can be performed in the same way that succes- 
sors of a segment in the same layer are evaluated. The 
route calculation routine compares the returned end 
points of the higher layer aggregated segments with the 
end points of each of the same layer successor seg- 
ments of the segment being evaluated. If one of the end 
points of the aggregated segment returned by the func- 
tion call provides a more promising solution route com- 
pared to all the same layer successor segments being 
evaluated (based upon the applicable criteria of the 
route calculation function), the route calculation function 
incorporates that portion of the r presented aggregation 
to its endpoint into the route being calculated. Specifi- 
cally, the route calculation routine uses the abbreviated 



record information associated with the aggregated seg- 
ment record to identify the segment records in the lower 
layer to be added to the calculated solution route to get 
to the promising end point of the aggregated segment 
5 in the upper layer. These segment records can be added 
to the solution route without any further evaluation, 
thereby avoiding time-consuming calculations. Once 
these lower layer records are added to the solution route 
to get to the end point of the aggregated segment, the 
higher layer data are evaluated to find further succes- 
sors. 

[0138] On the other hand, if the endpoints of the ag- 
gregated segment returned by the function call are not 
more promising as a solution route than the successors 
at the lower layer, route calculation continues at the low- 
er layer. Moreover, the route calculation routine may use 
this information to avoid any lower layer segments that 
lead to the endpoints of the aggregated segment since 
evaluation of these endpoints has already indicated that 
these are not promising locations from which a potential 
solution route can be found. 

[0139] This method described above provides an im- 
proved way to use aggregated segment records in a ge- 
ographic database. This method extends the advantag- 
es of using aggregated segment records (which are 
available at higher layers) to situations when the route 
calculation function is using lower layers of data. The 
disclosed method allows the aggregated segment infor- 
mation to be used even before an actual "jump" to the 
higher layer is made. This method has the potential for 
reducing the number of calculations that are required to 
be made during route calculation. This method is ena- 
bled, in part, by the upward references provided in the 
segment records in the layers below the highest layer 
n, which provide a means to quickly identify the aggre- 
gated segment records in higher layers that represent 
aggregations of road segments that include the road 
segment represented by the road segment record at the 
lower layer. 

b. Two ended searches 

[0140] As mentioned above, there are various navi- 
gation search techniques. One kind of route search 
technique determines an optimum route by calculating 
from both the starting location and the destination loca- 
tion and working toward the middle. When the two ends 
meet, a solution route is found. When aggregated, seg- 
ments are used, the search route from one end may in- 
clude an aggregated segment and the search route from 
the other end may include segments from a layer below 
which the aggregated segment is present. The dis- 
closed embodiments readily enable the segments in 
these two routes to be compared so that it can be de- 
termined whether a solution route has been found. 
[0141] As disclosed above in connection with a 
present embodiment, the aggregated segment records 
at each layer above layer 0 refer to abbreviated segment 
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and node records. As stated above, these abbreviated 
segment and node records are relatively close to tine ag- 
gregated segment records that refer to them. These ab- 
breviated segment and node records all include refer- 
ences to the segment and node records in layer 0 which 
represent the same segments and nodes that are rep- 
resented in aggregation by the aggregated segment 
records. When a two-ended search uses an aggregated 
segment, the layer 0 records that represent these same 
segments can readily be determined from the abbrevi- 
ated segment records associated with the aggregated 
segment. Using this reference information, the seg- 
ments in each route of a two ended search can readily 
be compared, thereby enabling the two-ended search 
to use a geographic database that includes aggregated 
segments. 

c. Real-time traffic 

[01 42] Another advantage provided by the disclosed 
embodiments is that they facilitate real-time traffic up- 
dates. Real-time traffic updates provide information 
about the current traffic conditions in a geographic re- 
gion to end-users of navigation systems. These updates 
may be provided to the end-users via a wireless com- 
munication system, such as radio broadcasts, cellular, 
and so on. These real-time traffic updates identify the 
locations of traffic jams, or may provide travel times 
along certain segments of roads in the geographic re- 
gion. The route calculation program in the navigation 
system can use the information in these real-time traffic 
broadcasts when calculating an optimum route. One 
way this is accomplished is to add a weighting factor to 
a normal travel time associated with certain road seg- 
ments when indicated by the real-time traffic informa- 
tion. These weighting factors applied to certain road 
segments may cause the route calculation program to 
select alternate road segments during calculation of a 
route thereby resulting in a different solution route being 
determined. 

[01 43] There are several different formats in which the 
real-time traffic broadcasts may be provided. In one em- 
bodiment, the real time traffic information is provided in 
a manner that enables weighting factors to be applied 
to road segment or node records in layer 0 of the routing 
data. If the navigation system is using an embodiment 
of the geographic database that includes aggregated 
segment records, a means is required that enables the 
real-time traffic information to be applied to the aggre- 
gated segment records so that the weighting factors can 
properly be taken into account when using aggregated 
segment records to calculate a route. 
[0144] This is accomplished by using the references 
in the abbreviated records 522 and 523 to which the ag- 
gregated segments 422 refer. As mentioned above, the 
abbreviated segment records 522 and abbreviated 
node records 523 which are associated with each ag- 
gregated segment 422 refer to the non-abbreviated seg- 



ment and node records at layer 0 that represent the 
same segments and nodes that the aggregated seg- 
ment record represents in aggregation. By means of 
these references to layer 0 segment and node records, 

5 a route calculation program using an aggregated seg- 
ment can readily identify the layer 0 segment and node 
records that represent the same segments and nodes 
represented in aggregation by the aggregated segment 
record. The route calculation program then determines 

10 whether any real-time traffic information has been asso- 
ciated with any of these layer 0 segment or node 
records. This can be done by maintaining a table that 
lists layer 0 segments and nodes that have weighting 
factors applied to them. In this manner a route calcula- 

IS tion program that uses aggregated segment records can 
take into account real-time traffic information when cal- 
culating a route. 

[0145] Alternatively, the upward references (e.g., ref- 
erence 648 in Figure 17) in the layer 0 segment data 
20 record 322 can be used to apply the real time traffic 
weighting factors to any higher layer aggregated seg- 
ment records that represent an aggregation of seg- 
ments that includes the segment represented by the 
segment record. 

25 

VI ALTERNATIVE EMBODIMENTS 

[0146] The embodiments described above represent 
only specific implementations of the inventive concepts 
30 disclosed herein. Various other implementations and al- 
ternative embodiments are considered to be encom- 
passed within the scope of the present disclosure. For 
example, in the disclosed embodiments, aggregated 
segment records are stored in higher layers that are 
35 physically distinct from the lowest layer (e.g., "layer 0") 
of data. In one alternative embodiment, separate layers 
of data may be provided without physically storing sep- 
arate layers. Instead, the separate layers may be pro- 
vided by suppressing certain ranks of the data during 
40 runtime of the navigation functions. Using suppression 
of ranks in this manner, some or all of the separate lay- 
ers may be combined and rank suppression may be 
used as needed to reduce the number of records to be 
examined instead of providing separate layers. 
45 [0147] In other alternative embodiments, aggregated 
segments and aggregated segment records may be 
formed in different ways. In the disclosed embodiments, 
using a rank attribute that defines separate layers rep- 
resents one way by which aggregated segment records 
so can be formed. However, in alternative embodiments, 
aggregated segment records may be formed without us- 
ing rank attributes. For example, aggregated segments 
may be formed by taking into account traffic patterns or 
vehicle usage. 

55 [01 48] In further alternative embodiments, the naviga- 
tion system should be understood to include any com- 
puter-based system that provides navigation functions 
to an end-user regardless of hardware platform or ar- 
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chitecture. For example, the navigation system may in- 
clude any kind of portable system, including hand-held 
systems, systems installed on personal digital assist- 
ants or notebook computers. In alternative embodi- 
nnents, the navigation system may include navigation 
application software installed on a personal computer, 
such as a desktop computer. Further, the navigation 
system may be implemented in various different envi- 
ronments, including networked environments and cli- 
ent-server platform environments. The navigation appli- 
cation program and the geographic database need not 
be located in the same location, but may be connected 
over a network. The geographic database may be locat- 
ed remotely from the end-user and the data transmitted 
to the end-user over a wireless communications link. 
[0149] In the embodiments described above, geo- 
graphic data were described as being parcelized. In al- 
ternative embodiments, the geographic data may not be 
parcelized or may be organized in a different manner. 
These data records may be either compressed or not 
compressed, 

[0150] In the embodiments described above, certain 
terminology is used to refer to components, data struc- 
tures, and so on, in the navigation system, application, 
and database. Other terminology nnay be used to refer 
to these kinds of entities and it is understood that the 
subject matter disclosed herein is not intended to be lim- 
ited to any particular terminology that expresses similar 
concepts. 

[0151] It is intended that the foregoing detailed de- 
scription be regarded as illustrative rather than limiting 
and that it is understood that the following claims includ- 
ing all equivalents are intended to define the scope of 
the invention. 



Claims 

1 . A geographic database stored adapted for use with 
a navigation application program run in a navigation 
system comprising: 

data entities that represent segments of roads 
in a geographic region and data entities that 
represent aggregations of segments of roads: 
wherein each of the data entities that represent 
segments of roads that represents a segment 
of a road that together with at least one other 
segment of a road forms part of an aggregation 
which is represented by one of the data entities 
that represent aggregations of segments of 
roads includes a reference thereto, 

2. The invention of Claim 1 wherein the geographic 
database is stored on a computer readable medi- 
um. 

3. The invention of Claim 1 wherein each of the seg- 



ments of roads has a rank that corresponds to one 
of a plurality of functional classes, wherein roads 
having a rank corresponding to a lower functional 
class are generally slower for travel than roads hav- 
5 ing a rank corresponding to a higher functional 
class, and wherein the segments of roads that are 
represented in aggregations by the data entities 
that represent aggregations of segments of roads 
all have a rank greater than a lowest rank. 

10 

4. The invention of Claim 1 wherein said geographic 
database is spatially parcelized into a plurality of 
parcels wherein each parcel of said plurality of par- 
cels comprises a separate plurality of the data en- 

15 titles, wherein the plurality of data entities in each 
parcel represent segments of roads encompassed 
together In an area of said geographic region and 
wherein the area that encompasses the segments 
of roads represented by the data entities in one par- 

20 eel is separate from the areas that encompass the 
segments of roads represented by the data entities 
included in the remainder of the parcels of a given 
level. 

25 5. The invention of Claim 1 wherein said geographic 
database is organized into a plurality of separate 
layers, wherein each layer includes a separate col- 
lection of data entities based upon functional class. 

30 6. The invention of Claim 5 wherein each data entity 
that represents an aggregation of segments of 
roads which Is referenced by a data entity that rep- 
resents a segment of a road is located in a higher 
layer relative thereto. 

35 

7. In a navigation system that includes a navigation 
application program, a geographic database stored 
on a computer-readable medium comprising: 

40 data entities that represent segments of roads 

in a geographic region and data entities that 
represent aggregations of segments of roads; 
wherein each of the data entities that represent 
aggregations of segments of roads refers to da- 

45 ta entities that are abbreviated representations 

of the segments of roads Included in the repre- 
sented aggregation, wherein each of the data 
entities that are abbreviated representations of 
the segments of roads includes a reference to 

50 a corresponding one of the data entities that 

represent segments of roads that represents 
the same respective segment of road. 

8. The invention of Claim 7 wherein at least some of 
55 the data entities that represent aggregations of seg- 
ments of roads are stored separately from the data 
entities that are abbreviated representations of the 
segments of roads included in the represented ag- 
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gregation. 

9. A geographic database for use in a navigation sys- 
tem that includes a navigation application program 
that uses said geographic database, wherein the 5 
geographic database includes: 

data entities that represent segments of roads; 
and 

data entities that represent aggregations of io 
segments of roads; 

and wherein the geographic database includes 
a plurality of separate layers that include sep- 
arate collections of the data entities based up- 
on functional ranks of the represented seg- 
ments of roads; 

and further within each layer the geographic da- 
tabase is spatially parcelized into a plurality of 
parcels each of which includes a separate 
grouping ol a plurality of said data entities 20 
based upon a proximity of the represented seg- 
ments of roads; 

and wherein each of the data entities that rep- 
resent an aggregation of segments of roads re- 
fers to data entities that are abbreviated repre- 
sentations of the segments of roads included in 
the represented aggregation and wherein the 
data entities that are abbreviated representa- 
tions of the segments of roads included in the 
represented aggregation are located in the 30 
same layer of the geographic database as the 
data entities that represent an aggregation of 
segments of roads thereas: and 
wherein each of the data entities that are ab- 
breviated representations of the segments of 3S 
roads includes a reference to a corresponding 
one of the data entities that represent segments 
of roads and which is located in a different layer 
relative thereto. 

40 

10. The invention of Claim 9 wherein all data entities 
that are abbreviated representations of the seg- 
ments of roads are located in a separate parcel from 
the data entities that represent aggregations of seg- 
ments of roads that refer to them. 

11. The invention of Claim 9 wherein the data entities 
that represent segments of roads that are refer- 
enced by the data entities that are abbreviated rep- 
resentations of the segments of roads are located 50 
in a layer that includes data entities that represent 
segments of roads of all functional ranks. 

12. A method of using a geographic database that in- 
cludes data entities that represent road segments 
and data entities that represent aggregations of 
road segments, wherein each of the data entities 
that represent road segments that represents a 



road segment that together with at least one other 
road segment forms part of an aggregation which 
is represented by one of the data entities that rep- 
resent aggregations of road segments includes a 
reference thereto, wherein the method comprises 
the steps of: 

evaluating a plurality of possible routes from an 
intersection along a potential solution route by 
comparing successor road segments of a road 
segment that leads to the intersection; 
with respect to the successor road segments 
which are represented by data entities that in- 
clude a reference to a data entity that repre- 
sents an aggregation of road segments, obtain- 
ing data associated with the referenced data 
entity that represents an aggregation of road 
segments; and 

using the obtained data associated with the ref- 
erenced data entity that represents the aggre- 
gation of road segments when comparing suc- 
cessor road segments from the intersection to 
ascertain whether a route incorporating road 
segments that form part of the aggregation rep- 
resented by the data entity that represents the 
aggregation of road segments meets an appli- 
cable criterion to be included as part of the po- 
tential solution route. 

13. The method of Claim 12 wherein the database is 
comprised of layers and the data entities that rep- 
resent road segments have ranks, and wherein 
each higher layer does not include data entities that 
represent road segments that have a rank that is 
less than that of the corresponding layer. 

14. The method of Claim 12 wherein each of the road 
segments has a rank that corresponds to one of a 
plurality of functional classes, wherein roads having 
a rank corresponding to a lower functional class are 
generally slower for travel than roads having a rank 
corresponding to a higher functional class, and 
wherein the road segments that are represented in 
aggregations by the data entities that represent ag- 
gregations of road segments all have a rank greater 
than a lowest rank, and wherein the method further 
comprises: 

after determining that road segments that 
form part of one of the aggregations represented by 
one of the data entities that represent aggregations 
of road segments meets the applicable criterion to 
be included as part of the potential solution route, 
using the higher layer of data corresponding to the 
layer that includes the data entity that represents 
the aggregation of road segments to find successor 
road segments from an end point thereof. 

15. The method of Claim 12 further comprising the step 
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of: 

upon ascertaining that the road segments that 
form part of one of the aggregations meet the ap- 
plicable criteria to be included as part of the poten- 
tial route, identifying the data entities that represent s 
road segments that represent the part of the aggre- 
gation represented by the road segments ascertain- 
ing the segments of data entities that represent ag- 
gregations of road segments to be included as part 
of the potential solution route meet an applicable to 
criterion to be included as part of the potential so- 
lution route. 

16. The method of Clainn 1 2 wherein the obtained data 
associated with the referenced data entity that rep- 
resents an aggregation of road segments include 
the end points thereof. 

17. A method of using a two ended search routine 
search with a geographic database that includes 20 
data entities that represent segments of roads and 
data entities that represent aggregations of seg- 
ments of roads, wherein each of the data entities 
that represent aggregations of segments of roads 

is associated with a reference by which the data en- 25 
titles that represent segments of roads that repre- 
sent the same respective segments of roads that 
are represented in aggregation by the data entities 
that represent aggregations of segments of roads 
can be identified, wherein the method comprises 30 
the steps of: 

building a potential solution route leading from 
an origin; 

building a potential solution route leading to a 3S 
destination; 

using the reference associated with a data en- 
tity that represents an aggregation of segments 
of roads included in either of the potential solu- 
tion routes to identify the data entities that rep- 
resent segments of roads that represent the 
same respective segments of roads that are 
represented in aggregation by the data entity 
that represents aggregations of segments of 
roads; and 

comparing the data entities that represent seg- 
ments of roads in the potential solution route 
leading from the origin with the data entities that 
represent segments of roads in the potential so- 
lution route leading to the destination to deter- so 
mine whether the two potential solution routes 
meet. 

18. The method of Clainn 17 wherein the reference as- 
sociated with each of the data entities that represent 55 
aggregations of segments of roads refers to data 
entities that are abbreviated representations of the 
segments of roads included in the represented ag- 



gregation, which in turn refer to the data entities that 
represent segments of roads. 

19. The method of Claim 18 wherein the data entities 
that are abbreviated representations of the seg- 
ments of roads included in the represented aggre- 
gation are located in a separate layer of data from 
the data entities that represent segments of roads. 

20. A method of using a navigation system with real 
time traffic updates, wherein the navigation system 
uses a geographic database that includes data en- 
tities that represent segments of roads and data en- 
tities that represent aggregations of segments of 
roads, wherein each of the data entities that repre- 
sent segments of roads that represents a segment 
of a road that together with at least one other seg- 
ment of a road forms part of an aggregation which 
is represented by one of the data entities that rep- 
resent aggregations of segments of roads includes 
a reference thereto, wherein the method compnses 
the steps of: 

obtaining the real-time traffic update data via a 
wireless communication; 

associating the real-time traffic update data 
with said data entities that represent segments 
of roads; 

with respect to each of said data entities that 
represent segments of roads to which said real- 
time traffic update data is associated, using 
said reference to associate said real-time traffic 
update data with data entities that represent 
aggregations of segments of roads referenced 
thereby . 
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